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

On Thu, 10 Aug 2000, Uri Guttman wrote:
>   CF> (i.e. Do we need another construct?)
> 
> i think we do because a thread can block on a mailbox while it can't on
> an array. 

Why not?

> also the mailbox idea allows delivery of signals and other
> asynch callbacks so it serves double duty. the idea is that the core
> manages it instead of the application. it has a builtin mutex so you
> don't have to use one or declare somthign shared. 

Which Perl should provide for all shared types anyway.
The only reason for explicit locking is to make a series of operations
atomic.

Given a general global @foo,

   pop @foo; 

should automagically lock and release @foo for the thread that's doing
the pop.

However, to preserve atomicity for @foo across mulitple accesses, you'd
need to specify a user lock.  The below would lock @foo for the entire
transaction, not just for the single access.

lock @foo;
my $a = pop @foo;
unshift @foo, $a * 4;
release @foo;

 > it does not stop you
> from sharing stuff but it provides an core level interface for
> comunications.

But based on what you said in another post, don't you think you would
want to institute a priority scheme for signal and event delivery? 
(Well, signals being the highest priority of the events, but events
generally have priorities as well.)  Should you really attempt to
interleave these with simple data sharing?

 -- 
Bryan C. Warnock
([email protected])