On Mon, Nov 05, 2007 at 02:36:27AM +0100, Marc Lehmann <[EMAIL PROTECTED]> 
> > > * 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))
       if (evwrite != NULL && evwrite != evread &&
           !(evwrite->ev_events & EV_PERSIST))

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

Reply via email to