dumb KSE question

[Julian Elischer]

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
> 
> 
>