<div dir="ltr">I started to look into fixing this issue, but HEAD no longer compiles for me. Here is the build error I get (on os x 10.8.2): <div><br></div><div><div>$ "inplace/bin/ghc-stage1" -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts -dynamic-too -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o"inplace/bin/ghc-stage1" -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts -dynamic-too -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o</div>
<div>/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc66530_0/ghc66530_1.split__2.s:unknown:missing indirect symbols for section (__DATA,__la_sym_ptr2)</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Mar 16, 2013 at 11:08 AM, Andreas Voellmy <span dir="ltr"><<a href="mailto:andreas.voellmy@gmail.com" target="_blank">andreas.voellmy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Fri, Mar 15, 2013 at 3:54 PM, PHO <span dir="ltr"><<a href="mailto:pho@cielonegro.org" target="_blank">pho@cielonegro.org</a>></span> wrote:<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I found the HEAD stopped working on MacOS X 10.5.8 since the parallel<br>
I/O manager got merged to HEAD. Stage-2 compiler successfully builds<br>
(including Language.Haskell.TH.Syntax contrary to the report by Kazu<br>
Yamamoto) but the resulting binary is very unstable especially for<br>
ghci:<br>
<br>
% inplace/bin/ghc-stage2 --interactive<br>
GHCi, version 7.7.20130313: <a href="http://www.haskell.org/ghc/" target="_blank">http://www.haskell.org/ghc/</a> :? for help<br>
Loading package ghc-prim ... linking ... done.<br>
Loading package integer-gmp ... linking ... done.<br>
Loading package base ... linking ... done.<br>
Prelude><br>
<stdin>: hGetChar: failed (Operation not supported)<br>
<br>
So I took a dtruss log and found it was kevent(2) that returned<br>
ENOTSUP. GHC.Event.KQueue was just registering the stdin for<br>
EVFILT_READ, whose type was of course tty, and then kevent(2) said<br>
"tty is not supported". Didn't the old I/O manager do the same thing?<br>
Why was it working then?<br>
<br>
After a hard investigation, I concluded that the old I/O manager was<br>
not really working. It just looked fine but in fact wasn't. Here's an<br>
explanation: If a fd to be registered is unsupported by kqueue,<br>
kevent(2) returns -1 iff no incoming event buffer is passed<br>
together. Otherwise it successfully returns with an incoming kevent<br>
whose "flags" is EV_ERROR and "data" contains an errno. The I/O<br>
manager has always been passing a non-empty event buffer until the<br>
commit e5f5cfcd, while it wasn't (and still isn't) checking if a<br>
received event in fact represents an error. That is, the KQueue<br>
backend asks the kernel to monitor the stdin's readability. The kernel<br>
then immediately delivers an event saying ENOTSUP. The KQueue backend<br>
thinks "Hey, the stdin is now readable!" so it invokes a callback<br>
associated with the fd. The thread which called "threadWaitRead" is<br>
now awakened and performs a supposedly non-blocking read on the fd,<br>
which in fact blocks but works anyway.<br>
<br>
However the situation has changed since the commit e5f5cfcd. The I/O<br>
manager now registers fds without passing an incoming event buffer, so<br>
kevent(2) no longer successfully delivers an error event instead it<br>
directly returns -1 with errno set to ENOTSUP, hence the "Operation<br>
not supported" exception.<br></blockquote><div><br></div></div></div><div>One thing we can easily do is have the new IO manager pass in an incoming event buffer so we can distinguish this case and treat it exactly as the old IO manager did. Then this exception would not occur and the waiting thread would just continue to retry the read until it succeeded. This is inefficient, but is no worse than the old IO manager. </div>
<div><br></div><div>Note that there is nothing about the IO manager that would cause the awakened thread to make a blocking read call - that is determined entirely by how the thread performs the read. For example, if you take a look at the code in the network package, you will see that whenever a socket is created, the socket is put in non-blocking mode. Then the code to receive from a socket does a recv() which is now non-blocking and calls threadWaitRead if that would block. </div>
<div><br></div><div>Going beyond this immediate fix, we can try to really tackle the problem. The simplest and arguably safest approach is probably to just use select for everything (on os x). That would have the downside of limiting the number of files that programs can wait on to 1024 per capability. </div>
<div><br></div><div>A better approach would be to try to register with kqueue and then if it doesn't work, register it with an IO manager thread that is using select for the backend. We can probably reuse the IO manager thread that is watching timers for this purpose. With the parallel IO manager, we no longer use it to wait on files, but we certainly could do that. That would save us from adding more threads. By only failing over to the manager-thread-using-select-backend if kqueue fails, we don't need to maintain a list of files types that kqueue works for, which might be a pain to maintain reliably. </div>
<div><br></div><div>-Andi</div></div></div></div>
</blockquote></div><br></div>