🚀 go-pugleaf

From article <1989Nov15.155723.4430@mks.com>, by alex@mks.com (Alex White):
> 
> Yes, but the question becomes, just how many different applications use
> these things?  A lot of things have been done under Unix boxes without
> threads.  Unix has the concept of fork, and people program to use that
> construct.  OS/2 has the concept of threads, and people program to use that
> construct.  The end result, is frequently the same.
> 
> I would also point out, that if its a good idea, then Unix will implement
> it very quickly and simply.  Given unix source, I could put some form
> of threads in place within a week.

Note that "UNIX" already has threads -- in MACH, which runs a BSD-like
system, with extensions.  And it seems likely that MACH will slowly 
replace older flavors of UNIX over the next ten years or so.  The big 
advantage to threads over fork is that fork is an expensive system call 
-- you have to allocate all the resources (virtual memory space, running 
context, etc.) for every fork call you make, and then these separate 
processes can't, for instance, share memory or do very clean communication.  
Threads cost very little to fire off, and therefore you can afford to use 
lots of them -- this is very very useful when you would like to do many 
things "at once".

Your argument about fork is very restrictive.  New technology is always
used in copycat ways for a while, but I submit that threads are significantly
more powerful than fork, and that many applications will be able to make
use of them to great advantage.  

Joe Hellerstein