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

At 12:18 PM 8/11/00 -0400, Uri Guttman wrote:
> >>>>> "NI" == Nick Ing-Simmons <[email protected]> writes:
>
>   NI> Uri Guttman <[email protected]> writes:
>
>   >> i think we do because a thread can block on a mailbox while it can't on
>   >> an array.
>
>   NI> Why not ? - I see no reason that a "shared" array could not have
>   NI> whatever-it-takes to allow blocking.
>
>then every op that could touch an array has to have code to support
>blocking.

Nope. The code that accessses the array needs to support it. Different 
animal entirely. The ops don't actually need to know.

>i think that would be a mess. and what is the definition of
>blocking on an array, is it empty? can i pop or shift it? how do you
>handle atomicity? how do you specify a non-blocking access (poll) on an array?
>
>mailboxes are defined to work fine with those requirements. a get on a
>mailbox will block until one item is retrieved and that is an atoamic
>operation. a get can be made non-blocking (polling) with a optional
>argument.

s/mailboxes/filehandles/;

If we're talking a generic communication pipe between things, we should 
overload the filehandle. It's a nice construct that provides an ordered, 
serialized, blockable, pollable communications channel with well-defined 
behavior and a comfortable set of primitives to operate on it.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[email protected]                         have teddy bears and even
                                      teddy bears get drunk