From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 12:27:11 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7C5137B401 for ; Sat, 12 Jul 2003 12:27:11 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C8643FEA for ; Sat, 12 Jul 2003 12:27:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <200307121927110150077rh6e>; Sat, 12 Jul 2003 19:27:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA59531; Sat, 12 Jul 2003 12:27:10 -0700 (PDT) Date: Sat, 12 Jul 2003 12:27:08 -0700 (PDT) From: Julian Elischer To: Petri Helenius In-Reply-To: <3F0FB225.50207@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Andrew Gallatin cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2003 19:27:12 -0000 On Sat, 12 Jul 2003, Petri Helenius wrote: > Julian Elischer wrote: > > >On Fri, 11 Jul 2003, Andrew Gallatin wrote: > > > > > > > >>We have a driver which will block a thread in a cv_timewait_sig() > >>after it calls into driver via an ioctl. Under libc_r, this will > >>naturally block the entire process until the driver wakes it up via a > >>cv_signal(). > >> > >>I assume that with KSE, the UTS will schedule another thread to run as > >>a result of calling the cv_timewait_sig()? Ie, it won't block the > >>entire process? > >> > >> > > > >yes, both libthr and libkse will allow your process to continue, sans > >thread. > > > > > > > Would this also work with netgraph? Say an userland process waiting for > "go ahead" signal at an ioctl in netgraph node (no data transfer > neccessary)? ANY thread that blocks in ANY WAY will cause the spawning of a new thread to do more work. Assuming that the ioctl blocks. netgraph doesn; impliment ioctls so I don't see how this si a netgraph question, unless the netgraph node is CALLING code that blocks.. (which would be a no-no) > > How expensive in relative terms is cv_signal? Should I moderate calls to > it if the above works fine othervise? In most cases the wait list would > be empty, so the question more or less is if I should have a separate > indication Userland cv stuff is relatively cheap in linkse. A bit more expensive in libthr but still cheap. > of somebody waiting for the condition or if the infrastructure of cv_* is > optimized enough to do that for me. I would probably be calling cv_signal > every time going out from interrupt context in the driver receiving > packets. Are you talking anout kernel or userland CVs? I need more info to understand the question.. > > Pete > > >