On Tue, Oct 24, 2017 at 11:14:22AM +0200, Martin Pieuchot wrote:
> This is not a problem. The way knote_acquire() is designed is to sleep
> for a small amount of time, 1 * hz for the moment.
Ah yes, I see the hz now.
So there cannot be starvation. This is a best effort algorithm,
we do not
On 23/10/17(Mon) 21:58, Alexander Bluhm wrote:
> On Wed, Oct 18, 2017 at 11:22:01AM +0200, Martin Pieuchot wrote:
> > Diff below is the last version of my kqueue diff to allow grabbing the
> > solock() and possibly sleeping, inside kqueue_scan().
>
> I wonder why you don't call knote_release()
On Wed, Oct 18, 2017 at 11:22:01AM +0200, Martin Pieuchot wrote:
> Diff below is the last version of my kqueue diff to allow grabbing the
> solock() and possibly sleeping, inside kqueue_scan().
I wonder why you don't call knote_release() when calling knote_drop().
Another thread could sleep in
Diff below is the last version of my kqueue diff to allow grabbing the
solock() and possibly sleeping, inside kqueue_scan().
Sleeping in kqueue_scan() is not a problem since threads are already
doing it when no event are available, in that case `kq_count' is 0.
When this happens, a thread going
