best ways to do clean up

[Juan Pablo L]

i sent the email below but it looks like it did not make it to the list and
i m not sure if you got it, any ways, it is below and i have an update, the
problem is not my custom ev_async the problem seems to be the ev_async type
in the libev library, i modified the the code, which is attached, to use
only libev's async watcher and the problem remains, please have a look.
thanks!


On 29 December 2010 18:23, Juan Pablo L <jpablolorenzetti at gmail.com> wrote:

> thank you very much for you help, this surely will be appreciated but i
> really dont want to keep the glib way of working with the
> loop, now that i have seen a better design :) ....  i worked around the
> issue of one of my custom events without altering the rest of the code,
> the code around this custom watcher,
> so it is ok now but my problem now is specific with libev, i think i m
> missing something big in libev but no matter how many times i read
> the libev documentation i still dont see where the problem is (maybe due to
> the fact that i m not an english native speaker), anyways, i have made
> a test program that  i m attaching here. in the real program i have the
> following flow, the main program starts a server thread, when the server
> thread receives a new connection it starts a connection thread, the
> connection thread start handlers threads to asynchronously handle queries
> from the clients, everything is fine but when the client disconnects or the
> connection is lost the connection thread asks the server thread to be killed
> (this action would also de-register the connection from the server) so the
> server thread calls the destroy function of the connection thread, the
> destroy function of the connecton thread  calls on the the handlers destroy
> functions to destroy all handlers, so as soon as the handlers are destroyed
> the connection thread is also destroyed and all resources in the server
> thread for that connection is also freed/destroyed. The problem is that the
> handlers thread hang (get stuck) while joining their threads because the
> ev_run never returns, from there everything is a problem i even get
> segmentation faults sometimes.
> i created a small test case that i m attaching that shows exactly my
> problem, i m sure is something easy but i just dont see it, in the real
> program it can work many times before hitting the problem (that is after
> many clients connections and disconnections and sometimes with the first
> client) ..... the files async_event.c and async_event.h contain my
> implementation of the custom watcher, the code is not too clean or commented
> but it is fairly easy and short. i m including an statically linked
> executable because it needs glib for the queue structure. thanks a lot!!!
>
>
>
>
> On 29 December 2010 16:42, Marc Lehmann <schmorp at schmorp.de> wrote:
>
>> 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
>>      -=====/_/_//_/\_,_/ /_/\_\
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20101230/9ee1fd07/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 1317 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20101230/9ee1fd07/attachment.c>