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

[Dean Herington]

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