#7216: Compositional blocking on file descriptors
---------------------------------+------------------------------------------
Reporter: AndreasVoellmy | Owner:
Type: feature request | Status: patch
Priority: normal | Milestone: 7.8.1
Component: libraries/base | Version: 7.4.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by AndreasVoellmy):
`threadWaitSTM` basically follows the template `threadWait`. `threadWait`
also ignores the result of applications of unregisterFd_, so on this point
it is no different than the code that is already in that module.
Regarding the result of `registerFd`: `threadWait` uses the result of
`registerFd` in only one place: it creates an empty `MVar`, registers a
callback that fills it and waits on the `MVar` handling any exceptions
thrown to the thread (it unregisters the callback on exception);
unregistering is the only place the result of `registerFd` is used.
`threadWaitSTM` does not block on an `MVar` (or anything else, that is
the point of it), so it cannot use the result of `registerFd` in the
same way. To accomplish the same thing on an exception (i.e.
unregistering the callback) we should probably return the registration key
in the result of `threadWaitSTM` so that the user can handle and
unregister. This would require also re-exporting the unregistration
function in `GHC.Event.Thread`, since it is currently exported from the
non-exposed `GHC.Event.Manager` module.
On the other hand, I don't really see why unregistering is
necessary for correctness. It seems to me like unregistering is an
optimization, since
it keeps the callback table smaller. If this occurs and the registered
file is ever ready, then the
callback will fire and be unregistered. If the registered file is
never ready, then the file will never be removed from the callback
table, but this could happen with a file anyway even when no error occurs.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7216#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
