Date: Thu, 6 Apr 2000 21:04:43 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Archie Cobbs <archie@whistle.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000406210443.I80578@prism.flugsvamp.com> In-Reply-To: <200004070107.SAA97591@bubba.whistle.com> References: <20000406002126.B80578@prism.flugsvamp.com> <200004070107.SAA97591@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000406210443.I80578>