All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: ell/main.c Memory leak
Date: Fri, 03 Jun 2016 18:56:04 -0500	[thread overview]
Message-ID: <57521914.7040804@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1606031529580.37295@mjmartin-mac01.local>

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

Hi Mat,

On 06/03/2016 06:17 PM, Mat Martineau wrote:
> On Fri, 3 Jun 2016, Denis Kenzior wrote:
>
>> 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.
>
> Seems like glib projects would have the same kind of problem, unless
> there are some restrictions on what happens in the cleanup code.
>

I don't recall ever having such issues.  I think glib allows loops to be 
restarted after main_loop_quit.  We could as well.

>
> Sure, I'm sold on needing something to clean up. Note that l_main_exit
> is already taken.

Which no one uses, so we can hi-jack that one.

>
>>
>> But if we add those two, how far away are we from supporting multiple
>> event loops?
>
> This keeps coming up. :)  Even if it's a rhetortical question, it's fun
> to ponder.
>
> Bundling up a bunch of globals in to an l_main struct is simple enough,
> but every idle and watch-based abstraction (timeouts, signals, ios, ...)
> would need to be told which event loop to use. I'm currently in the
> keep-it-simple camp on this one, but the right use case could always
> justify the feature.
>

Yes, but all of this can be hidden away from the API level.  First main 
event loop that is created becomes the default.  Then subsequent calls 
to l_idle_add, etc will always use the default main event loop.

If someone *actually* wants to use multiple event loops in the future, 
we can add API extensions to handle that.

Regards,
-Denis

      reply	other threads:[~2016-06-03 23:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 21:09 ell/main.c Memory leak Denis Kenzior
2016-06-03 22:05 ` Andrzej Zaborowski
2016-06-03 22:16   ` Denis Kenzior
2016-06-03 22:08 ` Mat Martineau
2016-06-03 22:25   ` Denis Kenzior
2016-06-03 23:17     ` Mat Martineau
2016-06-03 23:56       ` Denis Kenzior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57521914.7040804@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.