On Mon, 2004-11-29 at 22:56 +0000, Zefram wrote: > >A useful way to view this is that occurrence of the source > >event is not actually the arrival of the signal but triggers a > >counting of the signal. Source events generate target events on > >a schedule that depends on the operation of the event loop. > > "triggers a" should be "is triggered by the".
Maybe I'm being stupid again, but I don't follow you. Maybe the whole sentence should be rewritten. Here's what I think you're trying to say: It is important to understand the Event processing stages in detail. 1. Source event (a signal) 2. Event's counting of the signal 3. Target event, once something calls queue_pending 4. Target events are stored in a priority queue, possibly changing the order 5. Event callbacks are invoked by one_event() > The final sentence, out > of its original context, now says much less than it used to. You also > removed my sentence that said that reification could be forced; it's > relevant and I think important. I suggest that you now replace the > final sentence of the above with > > Reification can be forced when necessary. > > The schedule on which some other events are created is > non-obvious. This is especially the case with watchers that > watch for a condition rather than an event. In some cases, > target events are generated on a schedule that depends on the > operation of the event loop. I removed it because I found/find your phrasing unacceptably vague -- better to having nothing than a bunch of hedges. If you really want to explain how it works then better be specific. Perhaps the best solution is to take the 2-3 example scripts you've come up with and refer to them in the documentation. Can you put some specific example scripts together so I can include them? > Under queue_pending(), you removed the discussion of when it is and > is not called automatically. Understanding that is essential to using > it correctly. OK, how about this? =item queue_pending() Examines asynchronous source events (timers & signals) and reifies them as target events. C<queue_pending()> is called implicitly by C<sweep()> and C<one_event()>. NOTE: Signal watchers generate target events according to which watchers are active at the time that C<queue_pending()> is called rather than according to the time the signal is received. > >Think hard before you use C<queue_pending()>. Use of this API may > >indicate that your program is poorly designed. > > You seem to think that it is bad to use queue_pending(). It does in > fact solve some problems that otherwise occur with the Event interface, > namely the race conditions that I have pointed out. Needing to use it > does not indicate a bad program; merely one that's doing some complicated > things with signals. Hrumph. OK. > Under ->pending(): > > >last operation of the event loop. Even so, calling C<queue_pendig()> > >does not prevent a race condition -- it just makes it less likely. > > queue_pending() (which you mistyped) most certainly *does* prevent some > race conditions in this context. One might be looking for a signal that > one can be sure would have been received by now if it were to be sent at > all, but which one cannot be sure would have been received before the > last operation of the event loop. One might have the signal blocked, > with the change of signal mask being a watershed around which one wants > to classify signals into "before" and "after". These things are quite > common in non-trivial signal handling. > > Is your perception that queue_pending() doesn't fix race conditions the > reason for your comment about poor design? If a race condition is not > fixable, that truly is a mark of bad design. As I mentioned above, I believe the key thing which is needed here are example scripts. -- A new cognitive theory of emotion, http://openheartlogic.org
signature.asc
Description: This is a digitally signed message part
