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

Uri Guttman <[email protected]> writes:
>>>>>> "CF" == Chaim Frenkel <[email protected]> writes:
>
>  CF> How does this look different from an inter-thread visible array
>  CF> treated as a queue?
>
>  CF> 	Thread A
>  CF> 		push(@workqueue, $val)
>
>  CF> 	Thread B
>  CF> 		$val = pop(@workqueue)
>
>  CF> Where accessing the global variable is guaranteed by perl to be atomic.

Well either push should be unshift, or the pop should be shift 
or you haven't got a queue.

>
>  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 ? - I see no reason that a "shared" array could not have 
whatever-it-takes to allow blocking.

>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. it does not stop you
>from sharing stuff but it provides an core level interface for
>comunications.
>
>uri
-- 
Nick Ing-Simmons <[email protected]>
Via, but not speaking for: Texas Instruments Ltd.