* Kazu Yamamoto k...@iij.ad.jp [2012-09-21 10:29:22+0900]
Hello,
Non-threaded RTS would block FFI to C code. But it does not block file
descriptors and sockets because the scheduler uses select(). To my
experience, *simple* network programming with non-threaded RTS also
works well
Hello,
Non-threaded RTS would block FFI to C code. But it does not block file
descriptors and sockets because the scheduler uses select(). To my
experience, *simple* network programming with non-threaded RTS also
works well except the case where we reach the limit of file
descriptors for the
Hi cafe
looking at
http://www.haskell.org/haskellwiki/Simple_Servers
The last two solutions compared are forkIO vs. explicit event support
(based on what was System.Event).
Further reading appears to indicate that event support has been
integrated into the runtime.
Is it true that writing a
Hi,
Is it true that writing a simple server using forkIO now integrates
native event loops implicitly?
Yes.
IO manager handles event driven stuff. Thanks to this, we can enjoy
(light) thread programming using forkIO.
One last question. When writing C code, using epoll apis explicitly
can
Kazu Yamamoto (山本和彦) k...@iij.ad.jp wrote:
One last question. When writing C code, using epoll apis explicitly
can impose some blocking. Is the same to be said for GHC.Event?
I don't understand your question.
All system calls issued from the network package use non-blocking.
You don't
All system calls issued from the network package use non-blocking.
You don't have to worry about blocking at all.
Almost. Especially when interfacing with C code you should include the
-threaded option to GHC to link against the multi-threaded run-time
system. Otherwise your Haskell code
