Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals

Whatever the underlying implementation is, the wait until available
operation is needed. (I can never remember the name "V" or "P"?)

So it can be extended to do whatever is needed.

The other operation, lock with no-wait is a less obvious need. With
threads, why should it be needed? So that syntax could allowed to be
messier.

<chaim>

>>>>> "UG" == Uri Guttman <[email protected]> writes:

UG> pollable is a good thing. some mailbox designs are not pollable and some
UG> are. i like the idea of supporting polling then you can also have
UG> callbacks. but this does imply an implementation as semaphores and
UG> shared memory are not pollable. you would have to build this with pipes
UG> and filehandles.

UG> overlaying it on filehandles is another question. i would like to see a
UG> single operation which does an atomic lock, block, retrieve, unlock. we
UG> don't have that for filehandles.  you could use a new method on that
UG> special handle (i like 'get') which has the desired semantics.

UG> i think making mailboxes in some form is a good idea. but they should be
UG> special objects (even if they are filehandles) with their own methods to
UG> support the desired semantics.


-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183