threads (was Re: [gclist] Re: gclist-digest V3 #84)
Thu, 22 Jun 2000 23:41:52 -0400
At 3:02 AM -0400 6/22/00, Kragen Sitaker wrote:
>Joshua Burton wrote, rationally:
>> David Chase wrote:
>> > >The unglamorous way of saying this is: "You have just re-invented the
>> > >process."
>> > Yes and no. OS Interprocess communication is typically quite expensive.
>> Depends on the OS, of course. Threads are useful iff:
> > (1) Coroutines are too small (you can't trust me to yield to you), BUT
>Threads are also more flexible in when they can yield; you can be three
>levels down a call chain and yield to another thread. Doing this in
>coroutines requires that you allocate a separate stack for each
>coroutine, and poof, you've just written a userspace thread package.
Almost. The advantage of coroutines, in most languages (Scheme, Icon,
etc...) that inherently support them is that they are, surprise
surprise, garbage collected.
Using a thread in place of a coroutine means the thread not only
needs to yield "causing synchronization issues" but also needs to
know when to stop running - whereas in coroutines this is solved by
only running it on demand, and garbage collecting the activation
record of the coroutine when it will no longer be needed (can no
longer be needed because it is unreachable).
>See e.g. http://pobox.com/~kragen/minos, a tiny preemptive thread
>package my twin cousin Ben implemented with SIGALRM, setjmp, and
It looks interesting - is there some associated license? GPL? LGPL?
Or is it public domain? I'm tempted to use it.
Progressing further on this threads tangent:
Unix supports shared memory between two processes, and this is
precisely what threads are, only a different amount of memory is
shared. Yet processes are considered heavy and threads considered
light in Unix and Unix derivatives. Why is this?
Side note linking back to garbage collection:
The shared memory mechanism in Unix is garbage collected via
reference counting. That this is possible indicates that there may be
no cycles of shared memory, because shared memory may not refer to
shared memory, only processes may refer to shared memory. In theory,
life for the programmer might be made simpler if we unified the
notion of process and memory block - but I suspect this would end up
giving the operating system designer the task of non-trivial garbage
collection and of solving the actor problem - even on a
single-processor machine, hardly an easy task.