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.
If we're going to do this for real, then there's a few more things we need:
- we should probably annotate foreign calls with "interruptible" if they can be interrupted. That entails some changes to GHC, and to the way foreign calls get compiled: we'll need to pass an extra flag to suspendThread().
- the Task that has been cancelled needs to clean itself up
Sure.
- can we do this on Windows at all? It woud be even more useful on Windows where blocking I/O is done by foreign calls, and is currently non-interruptible.
We can do this on Windows, although the current state-of-the art in pthreads emulation is basically nicely asking the thead to terminate with a signal, and then forcibly suspending the thread and scribbling over %eip to point to some code that exits the thread. I'm not sure how this interacts with long-running syscalls...
- 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? Cheers, Edward