From owner-freebsd-arch Thu Apr 6 19: 1:32 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 C519537BFC1 for ; Thu, 6 Apr 2000 19:01:25 -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 EAA12667 for ; Fri, 7 Apr 2000 04:04:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA34826 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 04:01:24 +0200 (CEST) Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id A185F37BC1F for ; Thu, 6 Apr 2000 19:01:16 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id VAA39531; Thu, 6 Apr 2000 21:04:43 -0500 (CDT) (envelope-from jlemon) Date: Thu, 6 Apr 2000 21:04:43 -0500 From: Jonathan Lemon To: Archie Cobbs Cc: Jonathan Lemon , freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000406210443.I80578@prism.flugsvamp.com> References: <20000406002126.B80578@prism.flugsvamp.com> <200004070107.SAA97591@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004070107.SAA97591@bubba.whistle.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 06, 2000 at 06:07:11PM -0700, Archie Cobbs wrote: > Jonathan Lemon writes: > > I would like to solicit comments on the kqueue mechanism > > that I've been working on. Currently, it will report events > > for sockets, vnodes, and aio requests, and hopefully is > > designed to be extensible. > > > > An API document and rough code is at: > > > > 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: kn->kn_data = sbspace(&so->so_snd); if (so->so_state & SS_CANTSENDMORE) { kn->kn_flags |= EV_EOF; return (1); } if (((so->so_state & SS_ISCONNECTED) == 0) && (so->so_proto->pr_flags & PR_CONNREQUIRED)) return (0); return (kn->kn_data >= so->so_snd.sb_lowat); > > 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. > 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. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message