On Thu, Apr 29, 2004 at 05:16:22PM +0100, Zefram wrote:
> What really needs to be done with the Event API is not necessarily to
> get the cleanest handling of async events but to make it possible to
> handle them somehow. The API just doesn't permit these events to be
> handled properly. If you a
> "Z" == Zefram <[EMAIL PROTECTED]> writes:
Z> I've already got some thoughts about a better design. I think the
Z> best way to approach that is first to document exactly what
Z> interface Event has, as I've suggested. That would make it easier
Z> to see which bits are awkward. (Ex
Joshua N Pritikin wrote:
>Sure, but is Event really the perfect API design that we should try to
>implement perfectly? That would be an interesting discussion! What
>does Event do wrong and what would a better design look like ... ?
I've already got some thoughts about a better design. I think
On Mon, Apr 26, 2004 at 10:58:06PM +0100, Zefram wrote:
> Joshua N Pritikin wrote:
> >Yah, OK, but is there a real-world justification for running
> >asynccheck when creating signal watchers? Or is this just a
> >theoretical cleanliness argument?
>
> I haven't thought up a specific example where
On Mon, Apr 26, 2004 at 10:32:26PM +0100, Zefram wrote:
> Joshua N Pritikin wrote:
> >Because merely calling asynccheck never eliminates the race condition.
> >It just makes it "shorter."
>
> It does eliminate the race condition, in that it makes ->pending return a
> list of pending events that wa
Joshua N Pritikin wrote:
>Yah, OK, but is there a real-world justification for running
>asynccheck when creating signal watchers? Or is this just a
>theoretical cleanliness argument?
I haven't thought up a specific example where one would want to have
two watchers for the same signal and start th
Joshua N Pritikin wrote:
>Because merely calling asynccheck never eliminates the race condition.
>It just makes it "shorter."
It does eliminate the race condition, in that it makes ->pending return a
list of pending events that was correct at some point during ->pending's
execution. Also, the typ
On Thu, Apr 22, 2004 at 08:36:07AM +0100, Zefram wrote:
> And a final thought before I head off on holiday: consider the event
> sequence
>
> 0. start a signal watcher
> 1. receive a signal
> 2. start a second watcher for the same signal
> 3. send another signal
> 4. process events
>
> At the mom
On Thu, Apr 22, 2004 at 08:16:43AM +0100, Zefram wrote:
> Joshua N Pritikin wrote:
> >> 0. (bug) ->pending() should do an asynccheck
> >
> >That changes the documented behavior too much.
>
> How so?
Because merely calling asynccheck never eliminates the race condition.
It just makes it "shorter."
And a final thought before I head off on holiday: consider the event
sequence
0. start a signal watcher
1. receive a signal
2. start a second watcher for the same signal
3. send another signal
4. process events
At the moment, both watchers get events with hits=2. The correct
behaviour would be f
Joshua N Pritikin wrote:
>Ick. That's probably a bug. What I'm going to do is just drop any
>pending signals when you can stop(). Will that work for you?
Interesting. ->stop is actually documented to cancel pending events;
I hadn't noticed that before. So that change does seem to be necessary
On Wed, Apr 21, 2004 at 07:15:33PM +0100, Zefram wrote:
> Back to my SIGTSTP handler. Its basic operation is thus:
>
> 0. start
> 1. block SIGTSTP
> 2. stop the watcher, returning SIGTSTP to default handling
> 3. send a SIGTSTP to self
> 4. unblock SIGTSTP, thus letting the pending SIGTSTP be del
Back to my SIGTSTP handler. Its basic operation is thus:
0. start
1. block SIGTSTP
2. stop the watcher, returning SIGTSTP to default handling
3. send a SIGTSTP to self
4. unblock SIGTSTP, thus letting the pending SIGTSTP be delivered
5. after the process resumes, restart the watcher
6. end
I'm c
13 matches
Mail list logo
