Johann Höchtl
I might be wrong, but it's EPoll.hsc where you define the call to the Linux kernel function. This would be unneccessary, when poll (and kqueue and Windows equivalents) are already in the core. Ok, a bit more than EPoll.hsc would be unneccessary ;)
Not sure what you mean by "core"; see for instance the code for GHC's current I/O manager: http://darcs.haskell.org/libraries/base/GHC/Conc.lhs There's no special magic going on there, select() and friends are bound using the normal FFI mechanism.
What I mean is that applications like web servers should benefit immediately from a change in the exisiting core and not require a (new) library. So a change is likely neccessary in Network.Socket and http://hackage.haskell.org/packages/archive/network/2.2.1.5/doc/html/Network...Network.Socket.Internal and in the IO monad when it comes to files. http://hackage.haskell.org/packages/archive/network/2.2.1.5/doc/html/Network... If someone want's to benefit from more functionality, like overlapping IO on Windows, the extension may be platform dependent available. http://hackage.haskell.org/packages/archive/network/2.2.1.5/doc/html/Network... However, in order to produce portable code which uses non blocking IO "the new way", a programer should never have to think about the target platform. http://hackage.haskell.org/packages/archive/network/2.2.1.5/doc/html/Network...
Yes, of course. The idea would (or might) be to fold the event library
into GHC directly and rewrite the I/O manager in terms of it. Many (if
not all) of the library I/O functions may have to be adapted to work
with a new I/O manager. By writing it as a library first we can
a) write programs that use I/O multiplexing before support gets into
GHC core proper
b) ensure that the mechanisms are well tested and benchmarked before
they are integrated into GHC
G
--
Gregory Collins