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