RE: Bound Threads

[Simon Peyton-Jones]

| Maybe, the forkOS/forkIO approach is flawed, but I think we 
| should only rule it out when we can provide a convincing 
| example where only the keyword approach would work, and where 
| we can't use combinators to achieve the same effect.


Daan,

There has been extended discussion on this stuff, which Wolfgang and
Simon and I tried to boil out into a document.  It's hard to say exactly
what 'safe' or 'bound' exports, or whatever, might mean, so we give a
little operational semantics.

My hope is that the very same operational-semantic framework would serve
to describe your system. Would you like to write its transition rules,
in the same style?  Then we could compare the two more easily.   Without
that, I am hard pressed to understand the implications of what you
suggest, just as I was hard pressed to understand Wolfgang's proposal
till we had it specified.

You can find the document in the CVS respository in
haskell-report/ffi/threads.tex

Simon
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi

RE: Bound Threads

[Simon Peyton-Jones]

| Now, what I don't like about my proposal and your proposal is 
| that the user has to be aware of OS threads when making 
| foreign calls by wrapping it in "threadSafe" or adding 
| "threadsafe" sometimes -- but maybe that is unavoidable.

Actually, the proposal currently on the table, which no one has objected
to, is

* abolish the distinction between "safe" and "threadsafe"
* make "safe" the default (it already is)

So the user needs to do something special only if she wants to
do something unsafe (by adding "unsafe" to the foreign import).

Simon
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi