For what it is worth I favour Daan's approach, adding keywords to a language
seems to want for a sufficiently rich formalism/framework.
3) maybe we should also add "forkUnbound" that forks a haskell thread >
that can automatically be moved between OS threads.
In the spirit of searching for the most basic primitives - why not instead
define a primitive for moving haskell threads from os thread, as this
primitive seems to be required in any case in order to effect the
"automatic" movement between threads. Such a primitive would allow
alternative thread management strategies to be defined in haskell.
forkUnbound could then be implemented by registering the haskell thread with
the thread manager etc...
such a strategy would require explicitly identifying os threads - making
them almost first class, so to speak - is this bad ?
whilst ...
We never want to specify what OS thread is running a particular
Haskell thread.
in order to define strategies where the above is true, I believe we do need
to be explicit. These strategies can either be implemented by the rts, or in
a library. I think that the latter is better in the sense of more open.
explicit movement of Haskell threads between OS threads could potentially be
extended to thread migration between processes?
* "forkOS" doesn't have to use a new OS thread to run Haskell threads, just
when calling a foreign function, so it would work on Hugs too for example.
(as explained
why complicate matters, if forkOs/forkNative is supposed to fork a native
thread then why introduce exceptions, as is not forking of a native thread
part of the meaning of the operation?
_
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi