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
