Bound Threads

[mike V]

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