From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 00:01:12 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 6CA2B37B401 for ; Sat, 12 Jul 2003 00:01:12 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A7443FAF for ; Sat, 12 Jul 2003 00:01:11 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h6C70rsL066376; Sat, 12 Jul 2003 10:00:55 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0FB225.50207@he.iki.fi> Date: Sat, 12 Jul 2003 10:00:53 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 07:01:12 -0000 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)? 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 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. Pete