On Mon, 27 Jul 1998, Jim Doyle wrote:
> > Removing all trace of LWP from Coda would involve finding all the critical
> > sections and protecting them with mutexes, which would be very
> 
> Oh... Very scary. Now I see what this is not a trivial project.
> 
> Where would one start with such an endeavor, without disrupting
> the continuity of new feature development and bugfixes elsewhere
> in the Coda project?

I gather that Peter is somewhat busy this week, but I'm sure he'd have
much to say about this ;)

What I'd proposed earlier, but didn't do because there were many other
things to do for Coda was to :

1) Implement LWP on top of Pthreads. This should be straightforward, and
testable with the existing LWP tests.

2) RPC2 for Pthreads. Right now, RPC2 is built on top of LWP and consists
of various functions called by a thread that wants to do an RPC, and the
SocketListener, which is an LWP that listens for incoming packets and uses
LWP signals to hand that packet off to a worker thread that can process
it. The SL should itself become a Pthread, for reasons metioned before. It
should also fork new threads to handle new bind requests, since binds
involve several packets, this is the easiest way to save state between
packets. 
Since a LWP condition variable will be a wrapper for a Pthread condition
variable, it should not be too hard to handle both plain Pthreads that
want to make RPCs, and the Pthreads_that_behave_like_LWPs from part 1 hat
are also making RPCs. For all current users of RPC2, there should not be
any concurrency problems yet, but performance should improve.

3) Move tasks out of LWPs into preemptive threads. Since a mix of
preemptive and cooperative threads is supported now, tasks that are
CPU-intensive can have protections added and scheduled preemptively. I
beleive that RVM already works with pthreads, and I can't think of
anything cpu-intensive that isn't RVM related or encryption. IO
intensive threads should'nt benefit much over their current performance,
right? 
Encryption/compression can be paralellized very easily since it is done
right before the packet is sent, on a SMP system, we can let another LWP 
run while we are encrypting, since we know the next thing we will
do is send the packet, at which point the next LWP will get to run, so why
not start it early ? IF the critical sections in RPC2 are adequately
protected, this should be ok.

While this whole thing is more ugly than just replacing LWP, it delivers
most of the benefits without a hideous amount of work.

Shafeeq