mivori at hotmail.com
Sun Mar 16 01:56:56 EST 2003
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 ?
> 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.
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
More information about the FFI