Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kqueue: SIGIO?



> On the other hand, if kernel changes would be needed (for example to
> make SIGIO work with kqueue() on NetBSD) then we really should
> evaluate whether or not there is a better change that could be made
> to handle the situation, rather than just blindly making NetBSD the
> same as linux.   What that might be though I have no idea.

The first thing that comes to mind is a syscall that tells the kernel
to deliver signals, or at least certain signals, by changing a memory
location rather than arranging to execute code.  (I have trouble
imagining an architecture on which checking a volatile int variable is
more expensive than a syscall into the kernel.)

It is true, though, that that's more-than-zero cost in the loop.  But
it might be close enough to zero to be acceptable.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index