Date: Mon, 16 Sep 2002 12:39:47 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_timeout.c Message-ID: <200209161939.g8GJdlj87372@arch20m.dellroad.org> In-Reply-To: <84439.1032204014@critter.freebsd.dk> "from Poul-Henning Kamp at Sep 16, 2002 09:20:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp writes: > >Would an option to timeout() like SPAWN_SEPARATE_THREAD be a practical > >solution for some of these cases? I.e., optionally spawn a separate > >thread to handle the timeout() event. > > > >This may be expensive, but there may also be some timeout events that > >are rare, slow and expensive enough themselves to warrant using it. > > I'm not sure, this (or anything else) is the way to go. > > I have wondered if periodic events should be handled differently, > or at least separately from one-shots, but that is also just an > idea. > > I think what we need more than anything, is somebody gathering more > hard data and analyzing more... Certainly true.. and it may be the case that all uses of timeout() in the kernel today are "quick" and non-blocking enough that it's never necessary to spawn a new thread. However, "in general" when you have an event handler situation like this, there is no necessary reason to expect the handlers to all be "quick" functions. So it may be that by expanding the ability of timeout() to handle the more general case, we make it easier to use for other tasks. Just a possibility that would have to be put to the test of course. IMHO, I think there should be a much more generic event handler mechanism in the kernel that supports timeout events, user-defined events, etc., optional thread spawning, and user locking semantics that automatically handles race conditions. This has proven very helpful to me in the past, resulting in much simpler code. I have an example of this kind of API in mind, see the pevent(3) man page in libpdel (ports:devel/libpdel). Follow-ups to freebsd-arch.. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.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?200209161939.g8GJdlj87372>