Lex Spoon wrote:
> 
> John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> > on 7/20/00 8:01 AM, Lex Spoon at lex at cc.gatech.edu wrote:
> >
> > > Do you have a *rationale* for why the existing 1-semaphore primitives
> > > are insufficient?  Certainly the existing primitives are already
> > > implemented on all platforms, they are fast enough to saturate a 10 MBit
> > > network, and they are equally good under multithreaded access.
> > >
> > > I'm wondering if it would be worthwhile to just go back to 1-semaphore
> > > primitives, especially since it has the least impact on existing ports.
> > >
> > > -Lex
> >
> > You have thread (A) that reads data from a socket, and thread (B) that
> > writes data to the same socket. Thread (A) waits on read with Sempahore X
> > then thread (B) happens to wait on write on Semaphore X.
> >
> 
> Two gripes about this scenario.  First, why would you have a threading
> situation like this in practice?  Second, why stop with a reader and a
> writer--suppose two threads are both writing data to the same socket
> (probably a UDP socket)?  Or, what if one thread is watching for normal
> closes, and another is watching for errors?
> 
> But aside from that, there are two complete ways to solve this problem
> (if it needs solving) which don't need a VM change.  First, one can, as
> you pointed out, have a kind of semaphore that can be waited on by
> multiple threads.  Second, one can have a single thread listening on a
> socket, which then queries the socket and wakes up the appropriate
> thread--or maybe it just wakes up all interested threads and lets them
> decide for themselves.


It seems like it would help if we buffered the data in the VM.  This
would give us the speed, then we can use a Semaphore with a timeout
against the buffer to wait, On the readBuffer, it is a consumer
semaphore, aand on the write buffer it is a producer semaphore.  The
buffer is actually shared so we can allocate a chunk of memory and put
our messages there..  We would still have a very complicated switching
model so we could support the strange socket api in a backcompatable
way, though it would be nice to support an Event stream methinks.

Cheers,
Rob

> >
> >
> > PS Three semaphore model is good enough to saturate 100MBit via 500Mhz PB.
> >
> 
> Interesting.  Is this with an otherwise unmodified VM?  Also, has anyone
> compared *raw* performance on a regular 1-semaphore VM?  The 10MBit I
> quoted referred to was doing HTTP parsing in the loop, not just dumping
> data down the line.  If you've got some tests set up, and a 100MBit
> network handy, maybe we can do some really useful benchmarks.
> 
> -Lex

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!