Re: [i3] [PATCH] Use ev_break() rather than exit() in i3bar.

  • From: Fernando Lemos <fernandotcl@xxxxxxxx>
  • To: "Discussions/Questions about the i3 window manager" <i3-discuss@xxxxxxxxxxxxx>
  • Date: Sun, 11 Mar 2012 11:48:01 -0300

Hi,

On Sun, Mar 11, 2012 at 8:19 AM, DR <drdarkraven@xxxxxxxxx> wrote:

Sounds great, but I think it would be cleaner to avoid exporting so
many symbols. For example, for at least some of those calls to exit(),
can't we just make the function signal to the caller through a return
code that it has failed? The caller would then signal to his parent
and so on, until we get to the event handlers. Those handlers know all
state involved and can cleanly break out of the loop.

In case the last sentence became a bit confusing, consider this (->
indicates a function call):

Event loop -> Event handler -> A -> B -> C

If C called exit, you're now calling ev_break in C. But then you have
to export the symbols of stuff that needs to be cleaned up in the
event handler, in A and in B, so that you can clean up for them. If
you instead propagate the error across the call stack, C would clean
after itself and pass the error code to B, which would do the same and
pass the error code to A, and so on. That way no function has to clean
up after its parent.

That might require some refactoring (e.g. some functions might already
return something) but it's probably worth it.
If my understanding of ev_break() is right, my patch works quite the
same way as you described.
Event handler will return, and all the clean up is done in main(), no
extra symbols need to be exported.

Nope. You're cleaning up for the callers, then breaking out of the
loop the next time you return to the loop. What I suggested is that
you propagate the error to the callers and let the callers do the
clean up of their stuff, until you eventually get to the functions
that are called by the event loop itself, which should then decide
whether to break off the loop or not.

In the aforementioned example, function C should clean up its
resources and return an error code to B, which will then check that
return code, clean up its own resources and return an error code to A
and so forth. That way C doesn't have to know B's state, B doesn't
have to know A's state, etc. It's then much easier to manage, much
less likely that you forget to free some resources.

Regards,

Other related posts:

  1. Home
  2. i3-discuss
  3. Archive
  4. 03-2012