FFI, signals and exceptions
Edward Z. Yang
ezyang at MIT.EDU
Tue Aug 31 23:22:53 EDT 2010
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.
> > 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?
More information about the Glasgow-haskell-users