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 delivered
> 5. after the process resumes, restart the watcher
> 6. end
> 
> I'm concerned about what happens if another SIGTSTP is delivered before
> the signal handler blocks it (stage 1 above).  As things stand at
> the moment, in that case another SIGTSTP event gets queued.  After the
> handler finishes and returns to the event loop, the second SIGTSTP event
> gets queued, and the process suspends itself again.

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?

> 0. (bug) ->pending() should do an asynccheck

That changes the documented behavior too much.

> 1. (wishlist) a "cancel" method on event objects would be nice

Try the attached patch.

-- 
A new cognitive theory of emotion, http://openheartlogic.org
--- Event-0.88/c/signal.c       Thu Oct  5 23:19:44 2000
+++ Event/c/signal.c    Thu Apr 22 09:47:10 2004
@@ -63,8 +63,11 @@
     pe_signal *ev = (pe_signal*) _ev;
     int sig = ev->signal;
     PE_RING_DETACH(&ev->sring);
-    if (PE_RING_EMPTY(&Sigring[sig]))
+    if (PE_RING_EMPTY(&Sigring[sig])) {
        rsignal(sig, SIG_DFL);
+        Sigstat[0]->hits[sig] = 0;
+        Sigstat[1]->hits[sig] = 0;
+    }
 }
 
 WKEYMETH(_signal_signal) {

Attachment: signature.asc
Description: Digital signature

Reply via email to