Date: Sat, 12 Jul 2003 10:00:53 +0300 From: Petri Helenius <pete@he.iki.fi> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question Message-ID: <3F0FB225.50207@he.iki.fi> In-Reply-To: <Pine.BSF.4.21.0307111013350.40558-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0307111013350.40558-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F0FB225.50207>