#11 Better way to break out of inner mainloops

API
closed
nobody
None
5
2007-11-17
2007-11-06
No

Suppose I have one event_base that is event_loop'd 3 times. This easiely happens with GUIs and modal dialogs.
This means I have 1 main-eventloop and 2 modal-eventloops.

The callstack looks like:

event_loop() // 3
...
event_loop() // 2
...
event_loop() // 1
main

At some point in the future the exit condition for the inner loop (3) is reached and event_loopexit is called. This leaves the innermost mainloop (3). So far so good.

But under special conditions in my program the exit condition for the middle event_loop (2) is reached before that for (3). Now calling event_loopexit does leave loop (3) and stays in (2) forever.

Note that I don't want to exit loop (3) when only the exit condition for loop (2) is reached. But as soon as the exit condition for loop (3) is reached, both mainloops should return immediately.

This means that signaling the exit condition with event_loopexit doesn't work for me. I need something like this:

bool doexit = false;
event_loop( 0, &doexit )

// Later
doexit = true;

So every mainloop instance gets its own exit variable.

There is no need to add a special event to signal the loop exit because as soon as the current event handler returns the event_loop will be break'ed

Discussion

  • Nick Mathewson

    Nick Mathewson - 2007-11-06

    Logged In: YES
    user_id=499
    Originator: NO

    See also 1826546 event_base_loop_break()

    It's not completely the same use case, but a common solution for both would be great.

     
  • Scott Lamb

    Scott Lamb - 2007-11-07

    Logged In: YES
    user_id=360426
    Originator: NO

    I'm having trouble understanding this use case. To better understand it, I want to talk about what you're actually doing. Is this GUI example it or just a hypothetical? I'm not aware of any existing libevent-based GUI libraries. Are you creating a new one? porting an existing one to libevent?

    In particular, I'm not sold on the concept of recursive invocations of the same event_base at all. I know the Python-Twisted crowd frowns on this - anything you can do with nested invocations you can do with splitting the calling function in half.

     
  • Joerg Richter

    Joerg Richter - 2007-11-07

    Logged In: YES
    user_id=1582782
    Originator: YES

    Nested event loops are necessary for every GUI framework. Without it you couldn't write code like:

    if( showDialog( "Save changes?", YES | NO | CANCEL ) == YES ) ...

    Ok, this doesn't mean that it has to be the same event_base, but in my case there are also different event sources beside the GUI file descriptor. This GUI framework I am talking about is home grown with separated application and presentation processes. (like X)

    One other important event source is for example real time stock quotes. You don't want to stop the quotes just because some modal dialog shows up. So you have the choice to use a new event_base and add all needed events to it (GUI-fd and Quotes-fd), or re-loop the current event_base with all event sources already added. I do the later and it worked out fine so far.

    But to my original problem: I think I found a simple solution with the current interface:
    Something like (untested):

    void loopTillCondition( bool* cond )
    {
    while( !*cond )
    event_loop( EVENT_ONCE );
    }

    Except that this doesn't break the current loop always as fast as possible. Different callbacks will be called if needed in the current iteration. So this seems more correlated with 1826546 than first expected.

     
  • Scott Lamb

    Scott Lamb - 2007-11-07

    Logged In: YES
    user_id=360426
    Originator: NO

    Ahh, okay. I'm not sure I'd say "*every* GUI framework", as I wouldn't say having such an interface is a fundamental part of a GUI framework, but I do get your point. And fortunately it looks like nothing in libevent breaks with recursive invocations.

    If you're happy with event_loop_break() + EVENT_ONCE loop + external variable, then I am also. The event_loop(0, &doExit) you've mentioned seems doable but probably not worth the documentation/confusion cost of yet another function pair to invoke the main loop. (There are already event_{base_,}{dispatch,loop}).

     
  • Niels Provos

    Niels Provos - 2007-11-13

    Logged In: YES
    user_id=245089
    Originator: NO

    So, it seems we should go with event_loopbreak instead? And that would for work this particular case, too?

     
  • Joerg Richter

    Joerg Richter - 2007-11-13

    Logged In: YES
    user_id=1582782
    Originator: YES

    I doubt it would work the way I need it.

    Remember that I can have more than one event_loop of the same event_base.
    My need is to cancel a specific event_loop call and not only the inner-most one.

    But my problem is sufficiently solved with help of EVLOOP_ONCE.

    I don't need the missing feature to cancel a specific event_loop before the actual iteration is finished.
    So you can close this feature request if you want.

     
  • Nick Mathewson

    Nick Mathewson - 2007-11-17
    • status: open --> closed
     
  • Nick Mathewson

    Nick Mathewson - 2007-11-17

    Logged In: YES
    user_id=499
    Originator: NO

    Okay; if this is solved for you, I'll close the entry until somebody needs something trickier here. Thanks!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks