#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 Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs