Re: ell/main.c Memory leak

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

Hi Mat,

 >
> Maybe this is more of an iwd architecture problem than an ELL problem?
> The cleanup code runs after l_main_run() returns, and that code should
> not do anything that creates an idle or watch because those handlers
> will never get called. The event loop is already gone.
>
> The cleanup should be done before the main loop exits. Instead of
> calling l_main_quit to kill the daemon, create an iwd_quit function that
> will run all the teardown code first. Once teardown is complete, then
> call l_main_quit.

I've thought of this, but I wasn't really happy doing it that way.  The 
sequence of events would also be quite different from our GLib based 
projects.  If we want to make those projects easy to port to ell, this 
is not what we want.

However, there's another problem.

Various epoll sources can be created before the main event loop is 
started.  So if we init things, but fail prior to calling l_main_run for 
whatever reason, then again, epoll resources are not cleaned up.

>
> The associated problem is how to give better feedback to all users of
> ELL, so it's obvious when they're doing something they shouldn't.
> Changing where create_epoll is called could be a big help here. Rather
> than doing it automatically in watch_add, idle_add, and l_main_run, we
> could add an explicit l_main_init() function that must be called before
> l_main_run and any ELL functions that expect epoll_fd to exist.
> watch_add and idle_add would return errors if epoll_fd was 0. Yes, this
> is a lot like l_main_new/run/destroy, but calling it "init" doesn't
> create the impression that you can have multiple main loops.

Which is fine, but then we might as well add l_main_exit().

But if we add those two, how far away are we from supporting multiple 
event loops?

Regards,
-Denis