> many (most?) UNIXes, threads appear to be an afterthought.  Consider the
> semantics of fork() -- Solaris has two versions that describe different
> possible desired semantics (fork only the current thread active, or fork
> the entire process?  

Not really an afterthought in the long run...  pthread_create() lets you
create a new thread in the current protection boundary. fork() lets you
create a new thread in a new protection boundary.  The same exists 
with NT, you can create new threads or new tasks.

Java has already moved in this direction as well... The designers
have realized that it is necessary to give the applications programmers
the ability to create and manage multiple virtual machines, and communicate
with easily between VM boundaries. Being able to divvy up functionality
that runs in multiple protection boundaries can help you write more
scalable as well as more stable applications systems. Mainframers have
been doing this for years (double virtual machines and cross-address-space
function calls).


> What about signal delivery to other threads?  

I think most people will agree that signals were a good temporary 
solution for IPC in Unix that long-ago should have been refined for
something better. Its simply the case that Unix stagnated too long on
the signals solution and better solution to the problem of asynchronous
notification to processes wasnt provided in a nice portable way.

This is still the case today, people STILL rely on signals to send
notification to a process from the outside world. Using signals is
not so bad if you have threads available ; You can use dedicate a thread
to wait for the signal and use thread condition variables to communicate
the arrival of the signal to the rest of your program.  Synchronous
signals are best managed with the concept of exceptions, if you have
exceptions available.

Ultimately, Unix needs a more refined model of IPC than simply signals,
semaphores and message queues.  Mach ports solved this problem with
some elegance. NT uses an LPC (local procedure call) model that is
similar to Mach ports. Mainframes have cross-address-space function
calls, VMS has mailboxes. If Unix had a much nicer IPC messaging
facility, we'd not need to use signals for much of what we rely upon
then today.

Until that happens, the only other compromises I can see are to exploit
RPC on the local machine, or using SysV semaphores/messages queues
coupled with threads to do better interprocess communications and event
notification.

Still, Unix needs this kind of functionality... The ability to partition
an application into separate protection domains is very useful for 
many reasons.

> How should lock requests be handled in the child?  Pthreads does not address
> all issues involved in threading, so you can still hit on ambiguous
> cross-platform issues).  The traditional concept of "fork" does not mix
> well with user-land threading.  Java support classes, on the other hand,
> were really designed with threading in mind. 


> Threading is widely available under UNIX -- I just suspect it is not as
> widely used as in other architectures.

Its only a matter of time, people need to learn how to use and
exploit threads... This takes time.. Until then, people still resort
to the old fork(), pipe and signal models of IPC - often not because
they need protection boudaries :)  But rather, thats the only way they
know how to implement concurrent programs.

> I believe RPC2 current can handle preemptive multi-threading by virtue of
> a single critical section contaning all RPC2 code; there is a preemption
> package in LWP that RPC2 supposedly can coexist with.  However, I have not
> actually confirmed that this works.  

I guess I dont understand how LWPs are exploited by Coda... It seems
to me that your concern is that the non-preemptive nature of these
user-space threads and exploitation of that feature in the design of
Coda makes it hard to conceive a port to another Threads API. Maybe
I dont understand the subtlety of this because I havent looked at
the code long enough.. It would seem to me that you could retain the
same control of the threads scheduler by simply using condition
variables to force a scheduler context change from one thread to 
another thread... Condition variables are how you do interthread
communications - this is how you build programs where one thread
does some work and then passes control to another thread to do
some other work that you've prepared for it.

Could you explain what it is that isnt in Pthreads that makes
this conjecture difficult ?

-- Jim

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jim Doyle                         Boston University   Information Technology
Systems Analyst/Programmer        email: jrd_at_bu.edu   Distributed Systems
http://www.bu.edu/~jrd/ 			      tel. (617)-353-8248
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+-+-