Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Nov 2014 13:17:52 -0800
From:      Adrian Chadd <>
To:        J David <>
Cc:        "" <>, "" <>
Subject:   Re: How thread-friendly is kevent?
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Are you putting the same FD into multiple threads and hoping that only
one note will wake up on one listening kqueue?


On 9 November 2014 11:57, J David <> wrote:
> How thread-friendly is kevent()?
> In most cases, a dedicated thread does the kevent()-ing and
> dispatching work to the thread pool, but at extremely high rates that
> thread becomes a significant bottleneck.
> As an example, consider a pool of, say, 17 threads on a 16 core
> machine all in kevent() waiting for one of 32000 open TCP connections
> to be read-ready.  One connection becomes read-ready.  How many
> threads will have kevent() return with that event in eventlist?  Is
> there potential for a thundering herd problem?
> Limited small-scale experimentation suggests that only one thread
> returns per event, but it's not documented that way, so it's not clear
> if that behavior is intended, an implementation detail, or a
> coincidence that won't hold up at scale.
> Is this behavior at all guaranteed / by design / intentional?
> Although it would be ideal if so, it would also make sense to have to
> rely on EV_DISPATCH in multithreaded applications to prevent events
> from being delivered more than once, or to use EV_ONESHOT and re-add
> the event entirely, depending on which approach better suits the
> internal data structure the kernel uses for kqueue.
> Thanks for any advice!
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""

Want to link to this message? Use this URL: <>