[Haskell-cafe] Re: catting to cat gets stuck at > 135K
Simon Marlow
marlowsd at gmail.com
Mon Dec 1 08:22:34 EST 2008
Donn Cave wrote:
> Quoth Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
> | On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote:
> |
> |> The way this is usually handled in the non-threaded case is to either
> |> use SIGCHLD or non-blocking waitpid() so that "green" threads can
> |> continue running. I'm a little surprised this wasn't done.
> |
> | Yes, we've discussed this in detail a few months back. We even have a
> | partial implementation. However it stalled on needing a better signals
> | API which we have not managed to get through the standardisation
> | process.
> |
> | Unfortunately there is no non-blocking (non-polling) waitpid() and the
> | global (process-scope) nature of signals is a pain.
>
> SIGCHLD can be a pain in its own unusual way. Once you have a SIGCHLD
> handler, process exits will interrupt "long" I/O, so every such read(),
> recv() or whatever must now check for EINTR and restart. Even though
> the authors of GHC go to great lengths to convert all I/O to non-blocking
> anyway, this will still apply to external library functions that are
> beyond GHC's reach. So it's a strategy I would use only if I were kind
> of desperate.
We already have this issue since GHC's runtime uses a SIGVTALRM timer
signal for context switching and profiling. Indeed, it did cause trouble
with the editline library which doesn't test for EINTR in one or two
places, and we had to work around it by temporarily disabling the timer.
Still, it's standard practice to test for EINTR and all library code should
do it.
Cheers,
Simon
More information about the Haskell-Cafe
mailing list