On Mon, Oct 23, 2006, William Ahern wrote:
> > >From my reading of the kqueue code this isn't the case.
> > The change is 'bundled up' into the 'changes' array and kept there
> > until the next call to kq_dispatch().
> >
>
> Yet another reason why kqueue is superior to epoll? ;)
kqueue has a lo
On Tue, Oct 24, 2006 at 07:48:10AM +0800, Adrian Chadd wrote:
> On Mon, Oct 23, 2006, William Ahern wrote:
>
> > Note that with poll and select you don't lose much by shifting an event in
> > and out of a polling state. However, with things like epoll() and kqueue()
> > you potentially incur a sy
On Mon, Oct 23, 2006, William Ahern wrote:
> Note that with poll and select you don't lose much by shifting an event in
> and out of a polling state. However, with things like epoll() and kqueue()
> you potentially incur a system call everytime you do switch the notification
> state of each descr
On Mon, Oct 23, 2006 at 11:04:49AM -0700, Edward Chan wrote:
> HI there,
>
> I just started taking a look at libevent and had a couple questions.
>
> 1. are the event_* api's thread safe?
So far as you can guarantee there is no contention for the struct event and
struct event_base objects.
> 2.
