Current-Users archive

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

Re: kqueue: SIGIO?



On Wed, Sep 30, 2015 at 07:37:10AM -0400, Mouse wrote:
> > 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.)

Well, you can easily get that by just running a second thread that does
nothing but monitor the kqueue and deliver notification to the main
thread. That's a pretty standard design and all the OpenGL likely has
put at least one other thread into the X servere anyway.

Joerg


Home | Main Index | Thread Index | Old Index