RE: Bound Threads
[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... almost | 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 if 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 spec. 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 gain. Does anyone disagree with this? Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Bound Threads
Simon Peyton-Jones wrote:
[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.
That should be just a matter of copying from the ffi spec and adding an
additional specialid... I had hoped to avoid learning how to use yet
another TeX package... but OK, I'll do that.
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 spent about half an hour staring at a printout, before I saw that it
was all perfectly logical if I corrected one typo. Now I think there
are no typos left in the formal semantics, so it should need less
staring...
Anyway, do you think the proposal has been discussed enough for me to
start working on a prototype implementation?
About threadsafe/safe:
I think Wolfgang is saying that the apparent efficiency gain of not
requiring thread-safety is illusory, [..]
In GHC, we might be able to save some time, but only for calls without
call-back. As soon as there's a call-back, I can't see how we can save
any time at all.
[...] and so we can abolish the
safe/threadsafe distinction. I think that would be a very worthwhile
gain. Does anyone disagree with this?
Kill it kill it kill it! We don't need that distinction.
However, it might be worthwhile for other implementations of Haskell,
but we can't tell, because GHC is the only one that supports
"threadsafe" at the moment. Does anyone plan to add support for
multiple OS threads to Hugs or NHC?
If someone wants to keep "safe" in the FFI spec as an "optimization
hint", then that's fine for me, but something has to be done about the
misleading naming ("safe" is NOT SAFE) and an optimization hint should
never be the default. And it should be made absolutely clear that an
implementation may treat everything as "threadsafe".
Cheers,
Wolfgang
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
