From owner-freebsd-arch Thu Apr 6 19:54:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F071137C168 for ; Thu, 6 Apr 2000 19:54:28 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA15949 for ; Fri, 7 Apr 2000 04:58:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA34998 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 04:54:24 +0200 (CEST) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id E9BB837B62A for ; Thu, 6 Apr 2000 19:53:34 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id TAA02483; Thu, 6 Apr 2000 19:53:03 -0700 (PDT) From: Archie Cobbs Message-Id: <200004070253.TAA02483@bubba.whistle.com> Subject: Re: RFC: kqueue API and rough code In-Reply-To: <20000406210443.I80578@prism.flugsvamp.com> from Jonathan Lemon at "Apr 6, 2000 09:04:43 pm" To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Thu, 6 Apr 2000 19:53:03 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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