Re: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)

It turns out that, besides having a multithreaded process do `forkProcess` and `executeFile` "atomically", I also want to have a multithreaded process do `forkProcess` (without `executeFile`) and execute without any of the preexisting threads. This can be done by having a lock that all threads acquire before doing anything externally visible (roughly, any `IO` action), including, of course, the `forkProcess` itself. This solution, however, is cumbersome and probably inefficient. If a foreign function invocation designated "unsafe" is atomic with respect to the Haskell RTS, even when OS threads are used, there must be an internal mechanism in the Haskell RTS for temporarily running single-threaded. Why couldn't (and shouldn't) this mechanism be available to user programs? It would seem to be much cleaner and more efficient than the locking approach described above. Dean Simon Marlow wrote:
This example raises a general problem (which, as it turns out, is relevant to my current work). How can one mix multithreading with multiprocessing? In particular, how can a threaded process safely create another process to run a program? Put another way, how can the combination of `forkProcess` and `executeFile` be done "atomically enough" so that existing threads in the forking process don't "get in the way".
I read something on this topic (involving some sort of pervasive locking strategy) recently, but can't recall where. Anybody remember?
I can't think of a good way to do this at the Haskell level, because you'd need to halt all the running threads except for the one doing the fork. But one hack which will work is to call out to a C function which does the fork/exec, since foreign calls will be atomic from the point of view of the Haskell RTS. However, one caveat which might be relevant in the future is that if the Haskell program is running in a multi-threaded environment (i.e. OS threads, not Haskell threads), then the C function must be marked 'unsafe' for it to be treated as atomic by the Haskell RTS. The OS thread support in the RTS isn't fully implemented yet, though. Cheers, Simon
participants (1)
-
Dean Herington