[Haskell-cafe] Questions about threads

[Stefan O'Rear]

On Sun, Jul 29, 2007 at 05:35:26PM -0500, John Goerzen wrote:
> Hi everyone, 
> 
> I have been confused by some things about threads for a long time.  I'm
> hoping someone out there can help clear this up.  I'll clean up and
> document on the wiki if we get conclusive answers.
> 
> So it seems there are four scenarios for firing off threads:
> 
> A) Threaded RTS, forkIO
> B) Threaded RTS, forkOS
> C) Non-threaded RTS, forkIO
> D) Non-threaded RTS, forkOS
> 
> So the questions, for each of the four models, are:
> 
> 1) What is the impact of firing off a thread to execute a pure (non-IO)
> computation under each model?  Will multiple pure computations be
> allowed to run in parallel, or will only one run at a time?  (While the
> computation may be outside the IO monad, of course at the end it will
> have to use IO to communicate the result back.)

A) B) Parallel  C) D) Sequential

> 2) What is the impact of IO under each model?  Will GHC internally use
> select/poll/whatever?  Or will each thread get a dedicated OS thread
> that uses synchronous I/O?

GHC uses select/poll/whatever under all four models.

> 3) When signals are received, which thread receives them?

GHC never sends signals to threads.  Signals are handled by creating a
brand new thread to run your handler.

> 4) When forkProcess is executed, which thread(s) are duplicated to the
> forked process?

A) B) errorBelch("forking not supported with +RTS -N<n> greater than 1");
      stg_exit(EXIT_FAILURE)
C) D) Only the current thread (note, this means that the thread which
      serves Handle IO won't exist and said functions will lock)
 
> 5) What does an FFI import "safe" mean under each model?

A) C) A new OS-level thread is forked from a pool and the code is
      executed in it.
B) D) A dedicated OS-level thread is forked *at forkOS time*, and used
      for all safe foreign calles in the thread.  This is of course much
      more expensive, but makes TLS-using libraries like OpenGL work.

> 6) What does an FFI import "unsafe" mean under each model?

A) B) C) D) The code is executed inline (after saving caller-saves
            registers, of course)

> 7) What is the expected future level of support for each model?  This is
> of significant concern to me, as it appears that the threaded RTS is
> only supported on an extremely limited set of architectures (most
> programs won't even link on Debian's autobuilders if I use -threaded).
> Also I have heard comments that the non-threaded RTS may be dropped in
> the future.

A) B) High.
C) D) Unknown.  It depends on whether the threaded RTS can be made to
      interact in a remotely sane way with low level Unix programming
      (cf HSH).

> 8) What is the expected level of support for STM in combination with
> each threaded model?

A) B) Good.  Atomic instructions are used, along with a traditionally
      greedy-transactions model.
C) D) Very good.  No atomic instructions are needed, since the system
      simply refrains from preeemting during individual primops,
      including the commit.

> 9) How does par mix with each threaded model?  Is it equivolent to
> forkOS or forkIO?

A) B) Neither, it's a very low level operation which adds the node to a
      pool of things which should be executed.  The spark pool is read
      from when the runqueue is empty, and will not grow without bound
      since it's circular (old sparks are discarded)
C) D) newSpark is a noop

> Thanks, John

Notice that A/B and C/D are virtually equivalent. forkOS has *no effect*
on anything but safe foreign calls.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070729/4a3df0ff/attachment.bin