07/11/86 Event channels Event channels can be thought of as numbered slots in the interprocess communication facility tables. Each channel is either an event-wait, event-call, or asynchronous event-call channel. An event-wait channel receives events that are merely marked as having occurred and awakens the process if it is blocked waiting for an event on that channel. On an event-call channel, the occurrence of an event causes a specified procedure to be called if (or when) the process is blocked waiting for an event on any channel. On an asynchronous event-call channel, the occurrence of an event causes a specified procedure to be called whether or not the process is blocked. Naturally, the specific event channel must be made known to the process that expected to notice the event. For an event to be noticed by an explicitly cooperating process, the event channel identifier value is typically placed in a known location of a shared segment. For an event to be noticed by a system module, a subroutine call is typically made to the appropriate system module. A process can go blocked waiting for an event to occur or can explicitly check to see if it has occurred. If an event occurs before the target process goes blocked, then it is immediately awakened when it does go blocked. The user can operate on an event channel only if his ring of execution is the same as his ring when the event channel was created. The ipc_ subroutine is used as the primary interface to the Multics interprocess communication facility. The hcs_$wakeup entry point is used to wake up a blocked process for a specified event. Invoking an Event-Call Procedure: When a process is awakened on an event-call channel, control is immediately passed to the procedure specified by the input arguments to the ipc_$create_event_channel entry point. The procedure is called with one argument, a pointer to the following structure. This structure is declared in event_call_info.incl.pl1. dcl 1 event_call_info based aligned (event_call_info_ptr), 2 channel_id fixed bin(71), 2 message fixed bin(71), 2 sender bit(36), 2 origin, 3 dev_signal bit(18) unaligned, 3 ring fixed bin(17) unaligned, 2 data_ptr ptr; Structure elements: channel_id is the identifier of the event channel. message is an event message as specified to the hcs_$wakeup entry point. sender is the process identifier of the sending process. dev_signal indicates whether the event occurred as the result of an I/O interrupt. "1"b yes "0"b no ring is the sender's validation level. data_ptr points to further data to be used by the called procedure. Notes: A user should be familiar with interprocess communication in Multics and the pitfalls of writing programs that can run asynchronously within a process. For example, if a program does run asynchronously within a process and it does input or output with the tty_ I/O module, then the program should issue the start control order of tty_ before it returns. This is necessary because a wakeup from tty_ may be intercepted by the asynchronous program. If a program establishes an event-call channel, and the procedure associated with the event-call channel uses static storage, then the event-call procedure should have the perprocess_static attribute. This is not necessary if the procedure is part of a limited subsystem in which run units cannot be used. See the description of the run command for more information on run units and perprocess_static. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved