First, I'm sorry for the delay =) Marc Lehmann, el 14 de diciembre a las 20:10 me escribiste: > On Fri, Dec 14, 2007 at 11:39:59AM -0300, Leandro Lucarella <[EMAIL > PROTECTED]> wrote: > > First I have to figure out what to do with all the compile-time > > configuration that libev provide, I don't know if I will support all the > > configuration options. > > Its actually quite easy, there is only: > > a) EV_MULTIPLICITY you should support at least this beign set to 1, but with > the macros it should not be too hard to transparently support both. > b) EV_type_ENABLE you can simply check wether e.g. ev_stat is available > via #if EV_STAT_ENABLE, for the relatively few watcher types that can > be switche don or off. > > ev++.h supports all these options (I hope) and I think there aren't any > others that are user-visible, and its not that unwield.
Thanks for the tip. > The bigger problem you will face is that there are ten or so watcher types > as opposed to only one. I don't see this as a big problem. > > Methods callbacks should be supported too, as in eventxx. > > Looks good, and is closer to libev than ev++.h (in that the loop argument > is explicit). > > My only problem with such an API would be that all object orientation > seems a bit mood if I had to explicitly destruct my watchers (as to stop > them requires an external argument). Well, I'm not familiar enough with libev API, so I don't know if I undertand the problem you mention. Do you mean that if I do: delete watcher; that watcher could be active in some loop so if an event for that watcher comes it will use freed memory and blow? In that case maybe I can store the loop(s) (a watcher can be used in multiple loops, right?) a watcher belong to, and call stop() for all that loops in the watcher destructor. And taking a look the ev++.h do that, but stores a single loop pointer so I guess a watcher could only be associated to one loop at the time. > > And here's an idea about ho a single loop mode can be handled (but I'm not > > sure I will support this mode): > > It would probably be most cool if both modes could be handled via the same > code :-> What do you mean? Both modes are different by definition, if not, I guess there would be only one (which is what I asked for in the previos mail ;) [snip] > > Is there any chance to consider mantaining the API besides any > > configuration diferences? I think writing an extra loop parameter even > > when you are using the single loop mode worth the consistency gain and > > maintainance simplicity. > > I don't see the need for it, its trivial to write code that works in both > configurations already without such an argument. It should also be easy to > fake a loop in eventxx alone and simply not pass it to the functions. Check > out http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#MACRO_MAGIC, or > ev++.h, which uses this, and event.c, which also handles both cases). To be honest, I find it a little ugly to use macros all over the places. But I know is just a matter of taste =) > The only complication is in the dispatcher (as its basically a singleton What do you mean with 'dispatcher'? The default event loo? > object in one config and can exist multiple times int wo incarnations in > the other). If I had to implement it I would try a generic base class for > all loops and then subclass the default dispatcher from it, and then see > wether it helps to fake a struct ev_loop * or not. I don't think I'm following you... > And if there is a dispatcher object then individual watchers are trivial as > they cna then rely on the dispatcher being there all the time. I guess you are talking about the single loop mode, right? Thanks! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Agitamos toda la zona de la paleta al horno, vemos que una luz nos atraviesa toda la zona intestinal... -- Sidharta Kiwi _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
