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 simple server using forkIO now integrates native event loops implicitly? Or do I still need to create code that explicitly uses (what is now) GHC.Event? 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 know all of the changes I am discussing seemed to happen in ghc more than a year ago, sorry, I just can't find anything to explicitly guide me here. Thanks! Brad
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 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 have to worry about blocking at all. P.S. This article would help: http://www.iij.ad.jp/en/company/development/tech/mighttpd/ --Kazu
Kazu Yamamoto (山本和彦)
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 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 will block your C code and vice-versa. Also some concurrency features don't work properly in the single-threaded run-time. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.
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 will block your C code and vice-versa. Also some concurrency features don't work properly in the single-threaded run-time.
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 process. Anyway, I recommend to specify the "-threaded" option to GHC for network programming if you don't have special reasons. --Kazu
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 process.
I need to correct the last sentence. It should be "we reach the limit of select(), 1,024 file descriptors". --Kazu
* Kazu Yamamoto
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 process.
I need to correct the last sentence. It should be "we reach the limit of select(), 1,024 file descriptors".
Most of the modern systems provide a better alternative to select (epoll, kqueue etc.) which is used by the IO manager instead. They don't have such a low limit. Roman
participants (4)
-
brad clawsie -
Ertugrul Söylemez -
Kazu Yamamoto -
Roman Cheplyaka