best ways to do clean up

[Marc Lehmann]

On Wed, Dec 29, 2010 at 02:07:22PM -0400, Juan Pablo L <jpablolorenzetti at gmail.com> wrote:
> actually i already fixed my problem trying to follow libev way, my problem
> is that i m replacing all gilb loop things in an already built and working
> application

Well, the fastest way to get you going might be to embed glib in libev.
performance will not be great for those parts still using glib, but
roughly on par with what glib itself would provide.

Here is a working example on how to do that:

   http://cvs.schmorp.de/EV-Glib/Glib.xs

it basically works by using a prepare and check watcher to embed glib
maincontext into the ev loop.

that way, you can still reuse all your glib watchers and add code using ev,
which would also take care of the glib watchers.

> so i m trying to cause as little modifications as possible in the code, is
> not my intention to emulate glib with libev but i have to rebuilt some
> custom watchers originally in glib

but emulating glib (using glib itself) might make it much easier - you
would only fight libev, not libev and all of your upgraded code.

the choice is yours, of course, but if your program is big and
complicated, this might give you working results quickly.

> with libev and at the same time do not want to do big changes in the code
> which may lead to changes in the architecture ...
> i m just trying to get the best of libev
> and that can only be achieved following libev way of doing things.

the problem is that the very architecture and api themselves are slow.
it's an inherent feature of the design: if you keep the architecture of
how your watchers work, you will have little gains when using libev, in
fact, epoll + the glib way of doing things is quite a bit slower then
using e.g. poll.

the reason for this is that glib watchers don't represent specific event
sources, so they all have to be queried again and again - libev knows that a
timer is a timer with a specific timeout and an I/O watcher is an I/O watcher
for a specific fd, and doesn't need to look at it on each iteration.

while the glib design looks generic, it doesn't really do anything more
than you can do with libev and multiple watchers (probably at a lower cost
in memory even).

just combine all functions you want in a struct, as explained in the docs:

   struct mywatcher {
      ev_timer t;
      ev_cleanup c;
      ev_idle i;
      ...
   };

> good, i m just having little issues with libev but because there are things
> that i still dont have a clear understanding  .... for now this is fixed !!!

specific problems are much easier to handle than generic design issues.

what I can say from what you wrote is that trying to keep the glib design
has no inherent value over e.g. embedding glib into ev directly. in the
former case, you have to change your code, but the result will still be
slow. in the latter case, you don't have to change your code, and roughly
the same speed as with glib (when using select or poll as backends).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\