Date: Thu, 6 Apr 2000 19:53:03 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: jlemon@flugsvamp.com (Jonathan Lemon) Cc: freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <200004070253.TAA02483@bubba.whistle.com> In-Reply-To: <20000406210443.I80578@prism.flugsvamp.com> from Jonathan Lemon at "Apr 6, 2000 09:04:43 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon writes: > > > http://www.flugsvamp.com/~jlemon/fbsd > > > > Hi Jonathan.. Cool stuff! What about.. > > > > FILTER_WRITE > > > > connect sockets: > > socket has connected or failed to connect (same a select(2)'ing > > on a non-blocking socket after a connect(2)). > > I believe that is already handled right now; the filter will not > trigger until the socket is actually connected. If it fails to > connect, then it returns EV_EOF in the flag field. The actual code > for the socket write filter is: OK, good.. wasn't clear to me from the docs but I didn't read very hard. > > FILTER_CHILD > > > > Child process event. ident is the child PID. Returns same status > > as wait(4), etc. > > Hmm. Actually, you could have `FILTER_PID' to attach to an arbitrary > process in the system, so you get notifications when it goes away. > This might be useful for writing a monitoring tool which attaches > to (say) your webserver and database processes. I don't know if this > would be considered a security issue, since the information is probably > already available through other means. This would be very handy. wait() is one of those annoying blocking system call for which there is no select(2) equivalent .. instead, you have to catch SIGCHLD. > > FILTER_SIGNAL > > > > Signal received event. ident is the signal number. Overrides > > any signal handler for same (? wouldn't work for SEGV, etc :-) > > Queued signal delivery, with `data' giving a count of the number of > times the signal happened? I suppose you could do this, but I'm > not sure if it would be better than a normal signal() handler. I think it would be much much better and is IMHO required. Signal handlers are bogus because you can't do simple things like call malloc(3), etc (malloc is not reentrant and does not block signals). Also, signal notification in a select(2) based program requires setting up a secret pipe which you write to in order to wake up select(2) and to avoid a sigblock() race condition. As for Matt's comments.. "what he said" :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004070253.TAA02483>