From owner-freebsd-arch Mon Sep 16 12:45:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ED5C37B400; Mon, 16 Sep 2002 12:45:09 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF5A43E4A; Mon, 16 Sep 2002 12:45:08 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA09414; Mon, 16 Sep 2002 12:40:51 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g8GJdlj87372; Mon, 16 Sep 2002 12:39:47 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200209161939.g8GJdlj87372@arch20m.dellroad.org> Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: <84439.1032204014@critter.freebsd.dk> "from Poul-Henning Kamp at Sep 16, 2002 09:20:14 pm" To: Poul-Henning Kamp Date: Mon, 16 Sep 2002 12:39:47 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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