
On 01 March 2005 11:21, Marcin 'Qrczak' Kowalczyk wrote:
Marcin 'Qrczak' Kowalczyk
writes: Why is the main thread bound?
I can answer myself: if the main thread is unbound, the end of the program can be reached in a different OS thread, which may be a problem if we want to return cleanly to the calling code.
I've now implemented a threaded runtime in my language Kogut, based on the design of Haskell. The main thread is bound. The thread which holds the capability performs I/O multiplexing itself, without a separate service thread.
We found that doing this was excessively complex (well, I thought so anyway). The problem is, when there is no other work to do but there are outstanding I/O requests to wait for, the thread holding the capability has to wait in select(). But then, another OS thread making an external call into Haskell has to somehow indicate that it needs the capability, and wake up the thread blocked in select(). It can do this with a pipe, but then you still have the problem that each call-in requires a context switch, which is sub-optimal if you're implementing a library in Haskell to be called from another language.
Producer/consumer ping-pong is 15 times slower between threads running on different OS threads than on two unbound threads.
You might also want to measure throughput of call-ins. Cheers, Simon