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):
$ "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 /var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc66530_0/ghc66530_1.split__2.s:unknown:missing indirect symbols for section (__DATA,__la_sym_ptr2) On Sat, Mar 16, 2013 at 11:08 AM, Andreas Voellmy <andreas.voel...@gmail.com > wrote: > > > > On Fri, Mar 15, 2013 at 3:54 PM, PHO <p...@cielonegro.org> 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. >> >> However the situation has changed since the commit e5f5cfcd. The I/O >> manager now registers fds without passing an incoming event buffer, so >> kevent(2) no longer successfully delivers an error event instead it >> directly returns -1 with errno set to ENOTSUP, hence the "Operation >> not supported" exception. >> > > 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. > > 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. > > 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. > > 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. > > -Andi >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
