On Mon, Nov 05, 2007 at 02:36:27AM +0100, Marc Lehmann <[EMAIL PROTECTED]>
wrote:
> > > * multiple watchers can wait for the same event, there is no limitation
> > > to one or two watchers for signals and io.
> >
> > Could you give me an example of where that is important?
>
> There is actually a lot of code that relies on this just working, and the
> only other event loop I know that has a problem with this is Tk.
I forgot to mention that the resulting code is likely a tiny bit faster, and
certainly way less complex, then the multiple-case logic employed in some
libevent backends:
/* detecting wether evread or evwrite are wanted is not shown */
if (evread != NULL && !(evread->ev_events & EV_PERSIST))
event_del(evread);
if (evwrite != NULL && evwrite != evread &&
!(evwrite->ev_events & EV_PERSIST))
event_del(evwrite);
this juggling of two slots for read/write didn't feel right. The code to
check which watchers want which events and schedule them in ev basically
looks like this:
for (w = anfd->head; w; w = ((WL)w)->next)
if ((ev = w->events & events))
event (EV_A_ (W)w, ev);
Also, some backends do reference counting in libevent, some don't, and I
don't like completely different semantics unless there is a good technical
reason for them (epoll cannot easily detect closed fds, for example, a big
problem, but at least its something that cnanot easily be improved upon).
The goal obviously wasn't to make this ultra-efficient (its a
singly-linked list), but to make it possible on a small scale without
mysteriously failing on some backends.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkey.org/mailman/listinfo/libevent-users
