On Wed, 2008-09-17 at 13:44 -0700, Evan Laforge wrote:
> >> systems that don't use an existing user-space thread library (such as
> >> Concurrent Haskell or libthread ) emulate user-space threads by
> >> keeping a pool of processors and re-using them (e.g., IIUC Apache does
> >> this).
> > Your response seems to be yet another argument that processes are too
> > expensive to be used the same way as threads. In my mind pooling vs
> > new-creation is only relevant to process vs thread in the performance
> > aspects. The fact that people use thread-pools means that they think
> > that even thread-creation is too expensive. The central aspect in my
> > mind is a default share-everything, or default share-nothing. One is
> > much easier to reason about and encourages writing systems that have
> > less shared-memory contention.
> This is similar to the plan9 conception of processes. You have a
> generic rfork() call that takes flags that say what to share with your
> parent: namespace, environment, heap, etc. Thus the only difference
> between a thread and a process is different flags to rfork().
As I mentioned, Plan 9 also has a user-space thread library, similar to
> Under the covers, I believe linux is similar, with its clone() call.
> The fast context switching part seems orthogonal to me. Why is it
> that getting the OS involved for context switches kills the
Read about CPU architecture.
> Is it that the ghc RTS can switch faster because it
> knows more about the code it's running (i.e. the OS obviously couldn't
> switch on memory allocations like that)? Or is jumping up to kernel
> space somehow expensive by nature?
Yes. Kernel code is very different on the bare metal from userspace
code; RTS code of course is not at all different. Switching processes
in the kernel requires an interrupt or a system call. Both of those
require the processor to dump the running process's state so it can be
restored later (userspace thread-switching does the same thing, but it
doesn't dump as much state because it doesn't need to be as conservative
about what it saves).
> And why does the OS need so many
> more K to keep track of a thread than the RTS?
An OS thread (Linux/Plan 9) stores:
* Stack (definitely a stack pointer and stored registers (> 40 bytes on
i686) and includes a special set of page tables on Plan 9)
* FD set (even if it's the same as the parent thread, you need to keep a
pointer to it
* uid/euid/gid/egid (Plan 9 I think omits euid and egid)
* Namespace (Plan 9 only; again, you need at least a pointer even if
it's the same as the parent process)
* Possibly other things I can't think of right now
A Concurrent Haskell thread stores:
* Allocation area (4KB)
The kernel offers more to a process (and offers a wider separation
between processes) than Concurrent Haskell offers to a thread.
Haskell-Cafe mailing list