I created a ticket http://hackage.haskell.org/trac/ghc/attachment/ticket/7773/
for the problem reported by PHO. On Sat, Mar 16, 2013 at 5:07 PM, Andreas Voellmy <andreas.voel...@gmail.com>wrote: > 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
