Bound Threads

Simon Peyton-Jones simonpj at
Mon Mar 3 06:12:04 EST 2003

[I've updated the "Semantics for foreign threads" document by
re-ordering the sections a bit.  It'd benefit from having a bit more
formal syntax.  No one has commented a single word on the operational
semantics.  I don't know whether that's because it's so clear that no
discussion is needed, or so opaque that no discussion is possible.]

| > I must admit that I can't remember the
| > exact semantic distinction between those "safe" and "threadsafe"
| The problem is, nobody does... the original implementation didn't work
| in all cases. The original implementation made "safe" calls block all
| other haskell threads in some cases, and crashed in other cases.
| "Threadsafe" means that calling the foreign import shouldn't block or
| otherwise disturb other haskell threads. "Safe" means... well...
| nobody seems to know, and still fewer people agree on it.
| In the current "HEAD", there is no difference between threadsafe and
| safe. If someone comes up with a clear specification of why and how
| "safe" should be different from threadsafe, things might change again.

Indeed, the semantics in the "semantics of bound threads" document makes
no distinction between "safe" and "threadsafe" either.

The original intention was this:

	a threadsafe foreign call must not block Haskell threads, even
	the foreign call blocks in foreign land.

	a safe call is not required to obey this constraint

The motivation was that thread-safety might require more admin (e.g.
relinquishing the lock on the main Haskell heap), and this admin might
be costly.

A side consequence of GHC's implementation (albeit not of the above
specification) is that no Haskell threads progress during a safe call
(unless it provokes a call-back..?).  I recall that some people actually
started to rely on this, though it was never intended as part of the

I think Wolfgang is saying that the apparent efficiency gain of not
requiring thread-safety is illusory, and so we can abolish the
safe/threadsafe distinction.   I think that would be a very worthwhile

Does anyone disagree with this? 


More information about the FFI mailing list