[% setvar title IPC Mailboxes for Threads and Signals %]
|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
IPC Mailboxes for Threads and Signals
Maintainer: Uri Guttman <email@example.com> Date: 9 Aug 2000 Mailing List: firstname.lastname@example.org Number: 86 Version: 1 Status: Developing
An IPC mailbox is a simple way for threads (or possibly processes) to communicate without the mess of directly dealing with semaphores/mutexes/queues.
A mailbox is a combination of a semaphore and a message queue (or pipe). You put a message into a mailbox and can call get to retrieve it. The get call can be blocking or non-blocking but it can't be asynchronous unless it is built with or associated with a pipe/socket.
There can be special mailboxes created which can be used to synchronously deliver signals and warn/die callbacks. A thread can block on a signal mailbox and then when it receives the data and wakes up, it can proceed and safely do any needed work.
Mailboxes can be built in many ways. A single pipe could be used with just a reference (or C pointer) being passed down it. Then the async I/O system would handle delivery and the receiving thread could be woken up. Alternatively it could be a shared memory linked list with a mutex surrounding it. That would imply only a blocking API.
The kind of data you can send to a mailbox is a question. Some RTOSs have mailboxes where you can only send short data blocks. This is for efficiency and in many cases the data is just pointers to larger chunks. We could limit the data in a mailbox to a reference or an object if that simplifies coding them. Allowing an entire hash tree to be sent is not a good idea IMO.
Event.pm - XS based event loop module.
RFC #1 - Implementation of Threads in Perl
RFC #47 - Universal Asynchronous I/O (the moby one)
VMS - It has mailboxes
various RTOSs - They also have mailboxes