threads (was Re: [gclist] Re: gclist-digest V3 #84)

[Andrew Chen]

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
>

[snip]

>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
>longjmp.

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.