FFI, signals and exceptions

[Edward Z. Yang]

Excerpts from Simon Marlow's message of Tue Aug 31 05:02:13 -0400 2010:
> 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.

Gotcha.

> > 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?

Good point: we don’t distinguish between FFI calls that require thread
local state and which ones don’t: this might be a good thing to allow
annotating.  If we did know, then we could simply arrange for calls that
use thread-local state to run on those threads, and we would still be
able to farm out other FFI calls as necessary.

A technical question about cleaning up task: when I run freeTask on the
task, I get the following error:

Foo: internal error: invalid closure, info=0xb76fb418
    (GHC version 6.13.20100823 for i386_unknown_linux)

freeTask is only used from freeTaskManager, so I suppose it’s not quite
the right thing to do, however, as far as I can tell GHC doesn’t
have a current story for freeing tasks.  How should I proceed in figuring
out the cause of this error?

Cheers,
Edward