I/O manager: relying solely upon kqueue is not a safe way to go

[Simon Marlow]

On 15/03/13 12:54, PHO wrote:
> I found the HEAD stopped working on MacOS X 10.5.8 since the parallel
> I/O manager got merged to HEAD. Stage-2 compiler successfully builds
> (including Language.Haskell.TH.Syntax contrary to the report by Kazu
> Yamamoto) but the resulting binary is very unstable especially for
> ghci:
>
>    % inplace/bin/ghc-stage2  --interactive
>    GHCi, version 7.7.20130313: http://www.haskell.org/ghc/  :? for help
>    Loading package ghc-prim ... linking ... done.
>    Loading package integer-gmp ... linking ... done.
>    Loading package base ... linking ... done.
>    Prelude>
>    <stdin>: hGetChar: failed (Operation not supported)
>
> So I took a dtruss log and found it was kevent(2) that returned
> ENOTSUP. GHC.Event.KQueue was just registering the stdin for
> EVFILT_READ, whose type was of course tty, and then kevent(2) said
> "tty is not supported". Didn't the old I/O manager do the same thing?
> Why was it working then?
>
> After a hard investigation, I concluded that the old I/O manager was
> not really working. It just looked fine but in fact wasn't. Here's an
> explanation: If a fd to be registered is unsupported by kqueue,
> kevent(2) returns -1 iff no incoming event buffer is passed
> together. Otherwise it successfully returns with an incoming kevent
> whose "flags" is EV_ERROR and "data" contains an errno. The I/O
> manager has always been passing a non-empty event buffer until the
> commit e5f5cfcd, while it wasn't (and still isn't) checking if a
> received event in fact represents an error. That is, the KQueue
> backend asks the kernel to monitor the stdin's readability. The kernel
> then immediately delivers an event saying ENOTSUP. The KQueue backend
> thinks "Hey, the stdin is now readable!" so it invokes a callback
> associated with the fd. The thread which called "threadWaitRead" is
> now awakened and performs a supposedly non-blocking read on the fd,
> which in fact blocks but works anyway.

Interesting.  I think this may explain what I saw in this ticket:

http://hackage.haskell.org/trac/ghc/ticket/4245#comment:22

Cheers,
	Simon