wok view perl-event/description.txt @ rev 25037
Up glza (0.11.4)
| author | Pascal Bellard <pascal.bellard@slitaz.org> |
|---|---|
| date | Sat May 21 21:38:29 2022 +0000 (24 months ago) |
| parents | |
| children |
line source
1 The Event module provides a central facility to watch for various types
2 of events and invokes a callback when these events occur.
3 The idea is to delay the handling of events so that they may be dispatched
4 in priority order when it is safe for callbacks to execute.
6 Events (in the ordinary sense of the word) are detected by watchers, which
7 reify them as events (in the special Event module sense). For clarity, the
8 former type of events may be called "source events", and the latter
9 "target events".
10 Source events, such as signals arriving, happen whether or not they are
11 being watched. If a source event occurs which a watcher is actively watching
12 then the watcher generates a corresponding target event.
13 Target events are only created by watchers.
14 If several watchers are interested in the same source event then each will
15 generate their own target event. Hence, any particular source event may
16 result in zero, one, two, or any number of target events: the same as the
17 number of watchers which were actively watching for it.
19 Target events are queued to be processed in priority order (priority being
20 determined by the creating watcher) and in FIFO order among events of the
21 same priority.
22 Queued ("pending") events can, in some cases, be cancelled before being
23 processed. A queued event is processed by being passed to the callback
24 function (or method on a particular object or class) which was specified
25 to the watcher.
27 A watcher, once created, operates autonomously without the Event user
28 having to retain any reference to it. However, keeping a reference makes
29 it possible to modify most of the watcher's characteristics.
30 A watcher can be switched between active and inactive states.
31 When inactive, it does not generate target events.
33 Some types of source event are not reified as target events immediately.
34 Signals received, for example, are counted initially. The counted signals
35 are reified at certain execution points. Hence, signal events may be
36 processed out of order, and if handled carelessly, on the wrong side of
37 a state change in event handling.
38 A useful way to view this is that occurrence of the source event is not
39 actually the arrival of the signal but is triggered by the counting of
40 the signal.
42 Reification can be forced when necessary. The schedule on which some
43 other events are created is non-obvious. This is especially the case
44 with watchers that watch for a condition rather than an event.
45 In some cases, target events are generated on a schedule that depends
46 on the operation of the event loop.