On Wed, Dec 19, 2007 at 12:24:03PM -0300, Leandro Lucarella <[EMAIL PROTECTED]>
wrote:
> First, I'm sorry for the delay =)
np, we can do this in slow-motion just as well :)
> > 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.
Wow, great :->
> > 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?
Exactly that is what I meant.
> In that case maybe I can store the loop(s)
Yes! (thats what I do in ev++.h). The other approach would be to force the
user to do it, both are valid, the former is whta I would expect form a c++
api.
> (a watcher can be used in multiple loops, right?)
No! At least not at the same time. A watcher cna only ever be active (or
pending) in one loop.
> 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.
Yes! :)
> > > 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 ;)
They are diferent, but you can often handle different cases with the same
code, stupid example: template<typename t> T min(T a, T b) { ... }.
The code might become a bit harder to write (e.g. you have to use
"template" above, or in the case of libev, get a bit tricky with
EV_(A|A_|P|P_|DEFAULT|DEFAULT_)|other_stuff).
Your likely approach, I guess, would be to first write the generic loop
version and then decide wether you want to support EV_MULTIPLICITY != 1 (I
herewith offer my help).
If thats right, you cna happily just ignore the issue for the time being.
> > 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 =)
I'd rather have more and better macro-facilities!
Now, would you sitll oppose macros that much if they had an associated
namespace? That is atcually my only major grief with them (but I accept
that other people validly have other issues with them).
So.. you could even get fancy and do stuff like using a void (or int)
as loop in case no EV_MULTIPLICITY is used and work around the ensuing
problems with templates (or simply by copying around ints for example).
(Not trivial)
> > The only complication is in the dispatcher (as its basically a singleton
>
> What do you mean with 'dispatcher'? The default event loo?
Uh, no, "your dispatcher class" (or whatever it is called), which, as far
as I can see, encapsulates a single event loop, which would be both the
default loop and any additional loops, depending on how fancy you want to
get.
> > 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...
Ok, two cases:
a) we have a struct loop *, and thus a default loop AND multiple dynamic
loops
b) we only have the default loop, and no struct loop *.
Somethign like this is what I would try (forgive the bugs - pseudocode)
struct myloop
{
lots of goodies, such as loop (int flags), unloop and so on.
#if EV_MULTIPLICITY
struct ev_loop *loop;
myloop (int flags = 0) : loop (ev_loop_new (flags)) { throw if !loop }
protected: myloop(struct ev_loop *loop) : loop (loop) { }
#else
myloop (int ok) { throw if !ok }
#endif
}
struct default_loop : myloop
{
default_loop (int flags = 0) : myloop (ev_default_loop (flags)) { }
}
Would catch both cases without having to provide rather different
implementations.
You could make your watcher classes accept a struct myloop always
then. There will be further complications, of course, and it might be that
the approach turns out to be not nice at all.
So this is only how I would try to implement it first, and then see wether
it is reasonable.
> > 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?
Yeah, sorry.
Its a pleasure to talk to you, I have really little to explain except
reinforcing that your interpretation of my scarce comments are correct :)
In any case, since you know your trade, maybe another apprach would be not to
influence you and see what you come up with, it might be different, and
better....
--
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
