1[page_begin mem/event/gen]
2	[nav_link [mem/sf/txt]]
3<br>
4	[site_xref]
5<br>
6	[mp_xref]
7[page_content]
8
9This page contains internal documentation and thoughts regarding the
10generation of file events for memory based channels.
11
12[p]
13
14The current scheme is to use periodic timers with a small delay
15greater than zero.
16
17[p]
18
19While thinking about the implementation of [mem/mp/fifo2] the
20following idea came up: Queue a pseudo-file event, wait for it to
21wander to the front of the event queue and queue the next pseudo-file
22event for the channel during the dispatch and execution of the first
23event.
24
25[p]
26
27This idea was shot down after a deeper investigation of the way file
28events are generated and handled by the tcl core. See the
29[tcl/io/fevent] for a writeup of the results of this investigation.
30
31For this package the essential result of this investigation is that
32the new scheme would starve all other event sources as the notifier
33would never again call <b>Tcl_WaitForEvent</b> to wait for external
34events. Especially if the user happens to activate an event handler
35for <i>writable</i> events on a memory channel.
36
37[p]
38
39It seems that the current solution is the best we can do, well except
40for setting the delay on the timers to zero. This will allow other
41events (sources) to squeeze in while reducing delay (and thus the
42impact on their transfer performance) for memory channels to the
43minimum.
44
45Creating and registering a completely new event source would be
46possible too but has the disadvantage of difficult cross-version
47support as the internal interfaces to the notifier changed several
48times.
49
50[p]
51
52The only type of memory channel which can be further optimized is
53[mem/mp/fifo2] because both sides can generate and queue events for
54the other side whenever data is written into the appropriate memory
55buffers.
56
57[page_end]
58