1 07/11/86 Event channels
2
3 Event channels can be thought of as numbered slots in the interprocess
4 communication facility tables. Each channel is either an event-wait,
5 event-call, or asynchronous event-call channel. An event-wait channel
6 receives events that are merely marked as having occurred and awakens
7 the process if it is blocked waiting for an event on that channel. On
8 an event-call channel, the occurrence of an event causes a specified
9 procedure to be called if or when the process is blocked waiting for
10 an event on any channel. On an asynchronous event-call channel, the
11 occurrence of an event causes a specified procedure to be called
12 whether or not the process is blocked. Naturally, the specific event
13 channel must be made known to the process that expected to notice the
14 event. For an event to be noticed by an explicitly cooperating
15 process, the event channel identifier value is typically placed in a
16 known location of a shared segment. For an event to be noticed by a
17 system module, a subroutine call is typically made to the appropriate
18 system module. A process can go blocked waiting for an event to occur
19 or can explicitly check to see if it has occurred. If an event occurs
20 before the target process goes blocked, then it is immediately awakened
21 when it does go blocked.
22
23
24 The user can operate on an event channel only if his ring of execution
25 is the same as his ring when the event channel was created.
26
27 The ipc_ subroutine is used as the primary interface to the Multics
28 interprocess communication facility. The hcs_$wakeup entry point is
29 used to wake up a blocked process for a specified event.
30
31
32 Invoking an Event-Call Procedure: When a process is awakened on an
33 event-call channel, control is immediately passed to the procedure
34 specified by the input arguments to the ipc_$create_event_channel entry
35 point. The procedure is called with one argument, a pointer to the
36 following structure. This structure is declared in
37 event_call_info.incl.pl1.
38
39
40 dcl 1 event_call_info based aligned event_call_info_ptr,
41 2 channel_id fixed bin71,
42 2 message fixed bin71,
43 2 sender bit36,
44 2 origin,
45 3 dev_signal bit18 unaligned,
46 3 ring fixed bin17 unaligned,
47 2 data_ptr ptr;
48
49
50 Structure elements:
51 channel_id
52 is the identifier of the event channel.
53 message
54 is an event message as specified to the hcs_$wakeup entry point.
55 sender
56 is the process identifier of the sending process.
57 dev_signal
58 indicates whether the event occurred as the result of an I/O
59 interrupt.
60 "1"b yes
61 "0"b no
62 ring
63 is the sender's validation level.
64 data_ptr
65 points to further data to be used by the called procedure.
66
67
68 Notes: A user should be familiar with interprocess communication in
69 Multics and the pitfalls of writing programs that can run
70 asynchronously within a process. For example, if a program does run
71 asynchronously within a process and it does input or output with the
72 tty_ I/O module, then the program should issue the start control order
73 of tty_ before it returns. This is necessary because a wakeup from
74 tty_ may be intercepted by the asynchronous program.
75
76 If a program establishes an event-call channel, and the procedure
77 associated with the event-call channel uses static storage, then the
78 event-call procedure should have the perprocess_static attribute.
79 This is not necessary if the procedure is part of a limited subsystem
80 in which run units cannot be used. See the description of the run
81 command for more information on run units and perprocess_static.