New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vibe should exit when there are no more registered events #212

Open
CyberShadow opened this Issue Apr 6, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@CyberShadow
Contributor

CyberShadow commented Apr 6, 2013

One tell of a good asynchronous library is that the program will automatically exit when there is no more work to do. That is, the program may start up a few parallel HTTP requests, and exit once the last one was completed and processed. An HTTP server should quit by closing its listening socket; then, the program would exit after the last client HTTP connection was closed.

I noticed that Vibe instead determines when to exit by checking a flag in its event loop. I believe this approach is not ideal, as it will result in tasks terminating abruptly while waiting for an asynchronous operation to complete. In my ae library, I have instead implemented a centralized shutdown notification system (triggered by a signal / Ctrl+C, or from user code), which allows components to close listening ports, gracefully close long-running connections, stop timers, and perform a clean exit after completing all in-progress tasks.

Initially, I thought that Vibe's current behavior - to keep running, and waiting indefinitely for 0 events - was a defect in the libevent driver, however the same problem occurs with the win32 driver. It seems to be by design.

@CyberShadow

This comment has been minimized.

Show comment
Hide comment
@CyberShadow

CyberShadow Apr 6, 2013

Contributor

Just noticed, runEventLoop's documentation says:

The loop will continue to run until either no more event listeners are active or until exitEventLoop() is called.

So I guess it's a bug in the win32 and libevent drivers?

Contributor

CyberShadow commented Apr 6, 2013

Just noticed, runEventLoop's documentation says:

The loop will continue to run until either no more event listeners are active or until exitEventLoop() is called.

So I guess it's a bug in the win32 and libevent drivers?

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 9, 2013

Member

Exactly. The original intention was to make the event loop exit automatically once there are no event receivers, but for some reason libevent never exited. Then came the win32 driver and there it would have been an additional feature to implement. In the end both drivers were kept the same and I forgot about the issue.

Member

s-ludwig commented Apr 9, 2013

Exactly. The original intention was to make the event loop exit automatically once there are no event receivers, but for some reason libevent never exited. Then came the win32 driver and there it would have been an additional feature to implement. In the end both drivers were kept the same and I forgot about the issue.

@CyberShadow

This comment has been minimized.

Show comment
Hide comment
@CyberShadow

CyberShadow Apr 11, 2013

Contributor

Thanks for the reply. I had taken a closer look at the libevent event loop, and it looks like the goal of having the event loop exit automatically conflicts with the EVLOOP_ONCE flag, which is required for idle detection. There is the event_base_foreach_event function, which would allow manually determining whether there are any pending handlers, however it is only present in unreleased versions of libevent.

I think the functionality can be implemented as a manual counter...

Contributor

CyberShadow commented Apr 11, 2013

Thanks for the reply. I had taken a closer look at the libevent event loop, and it looks like the goal of having the event loop exit automatically conflicts with the EVLOOP_ONCE flag, which is required for idle detection. There is the event_base_foreach_event function, which would allow manually determining whether there are any pending handlers, however it is only present in unreleased versions of libevent.

I think the functionality can be implemented as a manual counter...

@CyberShadow

This comment has been minimized.

Show comment
Hide comment
@CyberShadow

CyberShadow Apr 13, 2013

Contributor

OK, I had another look today. Vibe's libevent code is fine - it uses behavior that's in the C API docs but not in the libevent book (event_base_loop will return 1 when there are no more events). The problem is the DNS stuff - once libevent's DNS subsystem is initialized, it will register its own events that will prevent the libevent loop from exiting until the libevent subsystem is shut down.

http://archives.seul.org/libevent/users/Dec-2009/msg00035.html

I suppose the conclusion is that this is simply a poorly-designed aspect of libevent, and we can't really do much about it.

Contributor

CyberShadow commented Apr 13, 2013

OK, I had another look today. Vibe's libevent code is fine - it uses behavior that's in the C API docs but not in the libevent book (event_base_loop will return 1 when there are no more events). The problem is the DNS stuff - once libevent's DNS subsystem is initialized, it will register its own events that will prevent the libevent loop from exiting until the libevent subsystem is shut down.

http://archives.seul.org/libevent/users/Dec-2009/msg00035.html

I suppose the conclusion is that this is simply a poorly-designed aspect of libevent, and we can't really do much about it.

@CyberShadow

This comment has been minimized.

Show comment
Hide comment
@CyberShadow

CyberShadow Apr 13, 2013

Contributor

Fix for Win32: 871c42c

Contributor

CyberShadow commented Apr 13, 2013

Fix for Win32: 871c42c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment