Joshua N Pritikin wrote:
>This release is for Zefram.
Thanks. Unfortunately we need to work some more on the documentation.
Some of the tweaks you made to my changes made the documentation
incorrect. There are also some tweaks that I think are misleading.
>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". 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.
Under queue_pending(), you removed the discussion of when it is and
is not called automatically. Understanding that is essential to using
it correctly.
>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.
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.
-zefram
