FFI, signals and exceptions

[Edward Z. Yang]

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