Calling the callback when event registration fails

Carter Schonwald carter.schonwald at gmail.com
Thu Feb 7 01:55:45 UTC 2019


under what circumstances would those failure modes happen where the process
can still run? (if need be, i can help you dig into the *BSD code bases if
we aren't sure when the  kqueue code would do that)

On Wed, Feb 6, 2019 at 7:10 PM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> Digging through the different backends, it looks like only the kqueue
> backend is even capable of returning False when modifyFd/modifyFdOnce is
> called. This happens when kevent returns eINTR or eINVAL. Why do we call
> the callback here instead of just throwing an error like we do in so many
> other cases?
>
> On Wed, Feb 6, 2019 at 5:44 PM Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> In the event manager's registerFd_, we find:
>>
>>     registerFd_ :: EventManager -> IOCallback -> Fd -> Event -> Lifetime
>>                 -> IO (FdKey, Bool)
>>     registerFd_ mgr@(EventManager{..}) cb !fd !evs lt = do
>>       ... <- ...
>>       (modify,ok) <- withMVar (callbackTableVar mgr fd) $ \tbl -> do
>>         ... <- ...
>>       -- this simulates behavior of old IO manager:
>>       -- i.e. just call the callback if the registration fails.
>>       when (not ok) (cb reg evs)
>>       return (reg,modify)
>>
>> A comment and a question. Comment: registerFd_ is only ever called in
>> contexts where exceptions are masked, so withMVar is doing some needless
>> mask/restore. Question: why do we immidiately call the callback if event
>> registration fails? This means that if event registration fails during
>> something like `threadWaitRead`, the end result would be that
>> `threadWaitRead` would just return immidiately. That doesn't seem good.
>>
>> --
>> -Andrew Thaddeus Martin
>>
>
>
> --
> -Andrew Thaddeus Martin
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190206/de446ca4/attachment.html>


More information about the Libraries mailing list