FFI, signals and exceptions

[Simon Marlow]

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