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