hmann wrote:
On Fri, Nov 22, 2013 at 05:24:24PM +0100, Jan-Philip Gehrcke
wrote:
I am working on gevent/gipc and need to figure out why a libev signal
watcher is still 'active' after destroying its originally assigned
event loop. In the example code at the bottom of this mail, I
T
Hello,
I am working on gevent/gipc and need to figure out why a libev signal
watcher is still 'active' after destroying its originally assigned event
loop. In the example code at the bottom of this mail, I
- create a signal watcher for SIGTERM
- assign it to the default event loop
- fork
- de
On 08.11.2012 22:12, Marc Lehmann wrote:
There isn't any intended behaviour, anything goes. Effectively you run
into undefined behaviour.
Okay, I understand that the application should not run into this
situation, so further questions are just for my understanding.
"Some backends (e.g. k
Hello,
I'm working on Linux 2.6.32. Consider the case where a file descriptor
is closed at some point *after* starting an IO watcher on this certain
file descriptor. How should the watcher behave in the moment of closure?
In a libev-based Python library I am using, it looks like the watcher
Hello,
ev_loop_fork() ensures that an event loop works properly in the child
after forking. After doing this, I would like to clean up the event
loop. I don't know if I get the terminology right -- I want to
deregister all events and re-initialize the event loop with the effect
that basically
