Re: kqueue microbenchmark resul

Re: kqueue microbenchmark resul

[Dan Kegel]

> >In fact, if you did leave the read queued in a daemon using select() 
> >before, you'd keep looping endlessly taking all CPU and never idle 
> >because there would always be read data available. 

That would be a programming error on the part of the application.
Any application using a level-triggered interface like select
or poll must of course mask off events it is not interested in,
to avoid getting them endlessly.  That's just 'select 101'.

> Also, level triggered notifications would also seem to cause 
> multiple thread wakeups and thundering herd problems when 
> there are multiple worker threads reading from the same queue. 
> 
> How does (?) kevent avoid this from happening? 

Easy - applications which have multiple threads reading from the
same queue would use oneshot events instead of level-triggered events.
Level-triggered events are only for applications where a single thread 
is reading from the queue.

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kqueue microbenchmark resul

[Marko Macek]

>In fact, if you did leave the read queued in a daemon using select()
>before, you'd keep looping endlessly taking all CPU and never idle
>because there would always be read data available.

Also, level triggered notifications would also seem to cause
multiple thread wakeups and thundering herd problems when
there are multiple worker threads reading from the same queue.

How does (?) kevent avoid this from happening?

Mark

--
... recursive make suxx!
------------------------------------------------------------------------
Marko.Macek@gmx.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/