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. The bigger problem you will face is that there are ten or so watcher types as opposed to only one. > 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). > 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 :-> > I think to multiple vs. single loop configurability is great, but it's a > little complex when using as a shared library and for making distribution > binary packages, since the API changes with that configuration. Aswith about any other config option, too, yes. There are no provisions to build without multiplicity or with disabled functionality when doing a distribution-like build: neither the libevent+libev tarball offers this nor will any mythical future standalone package support this. So if you want to limit yourself to those situations (as opposed to embedding), then supporting all watcher types and EV_MULTIPLICITY=1 will make it work in all sich configs. > 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). The only complication is in the dispatcher (as its basically a singleton 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. 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. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
