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 Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users