On Thu, Jan 17, 2008 at 10:28:16AM -0200, Leandro Lucarella <[EMAIL PROTECTED]>
wrote:
> > Bause I don't: I changed ->stat to ->update already and it sucks. The
> > obvious method would be to call them ev_sleep etc. (haha).
>
> do_/get_xxx? do_fork, do_sleep, get_time?
>
> fix_fork? go_sleep? now? (note that the now that gets the loop time is in
> the loop object in ev:: =)
I frankly don't know.
(as for now, I think then libev should have ev_now => ev_time, and ev_now
=> ev_loop_now, but thats ugly).
The prefix method, however ugly, is at leats consistent between C and C++.
But of course do_ is about the worst possible prefix. I can't come up with
anything better, sorry.
I guess the total rename is mostly the way to go then, i.e. deviate as
much as neccessary from the C API.
> > Another option would be to #undef sleep in the header file. Thats rather
> > drastic however and some people will hate us for it.
>
> Yeah, I think that would be pretty hardcore...
Says the guy who redefined throw().
On Thu, Jan 17, 2008 at 10:46:52AM -0200, Leandro Lucarella <[EMAIL PROTECTED]>
wrote:
> > That is pretty dumb to begin with.
>
> No, the problem is, for example:
>
> void cb (ev::io &w, int revents)
> {
> w.loop->unloop();
> delete w.loop;
> }
Thats pretty dumb to begin with, yes: deleting a loop that is actively
running in ev_loop *is* pretty dumb, and undefined behaviour will be the
punishment.
> This would be strange anyways, because you probably will know beforehand
> that *that* loop is really a dynamic or default loop.
Not just that, you are likely executing the callback form within ev_loop,
and freeing its memory while its still bein accessed is not going to work,
ever.
> OTOH if w.lopp is a loop_ref instead of a ev_loop*, you can't even do the
> delete w.loop because it's a value type. You should do something like
> w.loop.destroy (), but that destroy have to be virtual, unless
> ev_loop_destroy () can destroy both type of loops (which I think I could
> be nice and avoid some problems).
I think onyl the default destructor should destroy the loop. That practically
ensures that it works (and you already implemneted it that way :)
> Can I rely on ev_loop_{fork,destroy} accepting default loops when
> EV_MULTIPLICITY is set?
Definitely not, we should work aroundt hat way, even if inefficient, at the
moment, and later redesign those functions and optimise the ev++.h use.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
