> Let's summarize the questions:
>
> * Will safe FFI calls eventually be executed by extra OS
> threads?
> * Would you support additional synchronization primitives in
> the RTS (and `Concurrent') to support making the use of
> libraries like GTK+ thread-safe?
> * How about three kinds of FFI calls?
I would welcome advice on these points.
Indeed, we have not yet implemented the 'safe call executed in
another thread' mechanism.
The motivation is this:
An I/O call can block, and we don't want that to
freeze the entire Concurrent Haskell program.
The current "solution" is this:
use 'select' to avoid committing to a particular I/O call
until you are sure it won't block
Alas, select is not supported in the new RTS yet, but
we plan to support it shortly. Also 'go to sleep for 4 seconds'
This "solution" is not good:
it relies on I/O libraries that can accurately predict
blocking
it relies on the programmer to get it right.
Our proposed solution is this:
Have lots of OS "worker threads", plus an OS lock for the
entire heap and scheduler data structures.
Each worker thread tries to get the lock, at which point
it busily executes all the Concurrent Haskell threads in
the heap
Before a potentially-blocking FFI call, the worker tidies
things up and releases the lock. Then it makes the call,
and re-acquires the lock. If the I/O call doesn't block,
it may get the lock back before any of the other worker
threads get it.
If the I/O call does block, another worker thread gets the
lock, and executes Concurrent Haskell threads.
Maybe there ought to be some way for the returning OS thread
to ask the current worker to back off, so that it's not
shut out indefinitely.
Of course, this solution does indeed require libraries to be
thread safe.
I know of no way to support
a) non-thread-safe libraries
b) I/O calls that can block without freezing the entire
Concurrent Haskell program.
This is not a new problem, of course. But I don't know of any
better solutions. The one above is (I believe) used by CAML.
Comments?
Simon
