On 28/08/2010 07:45, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Fri Aug 27 04:05:46 -0400 2010:
You should walk cap->suspended_ccalls instead, no lock is required for that.
For stress testing, you want to construct an example that has lots of
threads making foreign cals and other threads calling throwTo to
interrupt them.
Will do.
So this is a proof of concept, and it seems to work - great!
This approach of killing threads unceremoniously also seems to have
garnered a lot of bad juju in other contexts (Java, for example, lets
you terminate threads, but the function that does so is deprecated,
since guaranteeing that a thread cleaned up properly in a stateful
environment is really, really hard.) Maybe we should just use pthread_kill()
to send a signal to the thread.
I think the idea of annotating interruptible calls should be good
enough. Simple blocking system calls like "read" can all be annotated
as interruptible without any problems. Also, pthread_cancel() provides
ways to control when cancellation can occur - a thread can say whether
it allows cancels at any time or only at cancel points, so that will
allow critical sections to be protected, and allow more complicated
foreign calls to be made interruptible too.
- bound threads: we can't cancel a bound thread, because then there's
no way to return to the caller (a bound thread results from a call
to a Haskell function from C). This makes the programming model
slightly unpleasant, because a foreign call will only be
interruptble when called in certan contexts, but I don't know what
to do about that.
It seems to me that the obvious thing to do is only allow bound FFI calls
to run on bound threads. What goes wrong with this approach? Is the
waste of threads too severe?
Not sure what you mean here: what's a bound FFI call?
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
