I have just spend some time reading through all the discussions and the new "threads" document and I would like to propose the addition of a new library function.
forkOS :: IO () -> IO ThreadID
The function "forkOS" forks a new Haskell thread that runs in a new OS (or native) thread. With this, I also propose that "forkIO" always runs a Haskell thread in the same OS thread that the current Haskell thread runs in. (i.e. "forkIO": same OS thread, "forkOS": new OS thread)
Using the new primitive, we can view the new "threadsafe" keyword as syntactic sugar:
foreign import threadsafe foo :: Int -> IO Int
===>
foo :: Int -> IO Int foo i = threadSafe (primFoo i)
foreign import "foo" primFoo :: IO Int
where
threadSafe :: IO a -> IO a
threadSafe io
= do result <-newEmptyMVarforkOS (do{ x <-io; putMVar result x })
getMVar result
Note that "forkOS" can use thread pooling in its implementation.
The advantage of a separate function "forkOS" is that we put control back to the users hands, as a programmer can be very specific about which Haskell threads are part of a certain OS thread and can be specific about the OS thread that is used to run a foreign function. On other words, it is absolutely clear to which OS thread a Haskell thread is bound. In this respect, it helps to have another function that runs a Haskell thread in a specific OS thread.
getOSThread :: ThreadID -> OSThreadID forkIOIn :: OSThreadID -> IO () -> IO ThreadID
I have the feeling that it is not difficult to implement "forkOS" and family once the runtime system has been upgraded to support multiple OS threads. Wolfgang, you seem to be the expert on the OS thread area, would it be hard?
---- I am not saying that we should discard the "threadsafe" keyword as it might be a useful shorthand, but I think that it is in general a mistake to try to keep the management of OS threads implicit -- don't use new keywords, add combinators to implement them!
I feel that the following has happened; urk, we need some way of keeping haskell threads running while calling C; we add "threadsafe"; whoops, sometimes a function expects that it is run in the same OS thread; we add "bound"; whoops, sometimes functions expect to be run from a specific OS thread... unsolved?? Before we know it, we have added tons of new keywords to solve the wrong problem.
Maybe it is time to take a step back and use a somewhat lower level model with two fork variants: "forkIO" (in the same OS thread) and "forkOS" (in a new OS thread). It seems that none of the above problems occur when having explicit control. In general it seems that OS threads are a resource that is too subtle to be managed automatically as they have a profound impact on how libraries are used and applications are structured.
All the best, Daan.
"worse is better" :-)
_______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
