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
