[Libevent-users] Re: libevent 2.1.11-stable breaks the links browser

[Mikulas Patocka <mikulas@xxxxxxxxxxxxx>]

On Fri, 30 Aug 2019, Azat Khuzhin wrote:

> On Thu, Aug 29, 2019 at 06:38:48PM +0200, Mikulas Patocka wrote:
> > Hi
> > 
> > The patch 497ef904d544ac51de43934549dbeccce8e6e8f8 ("Warn if forked from 
> > the event loop during event_reinit()") breaks the links browser when it is 
> > compiled with libevent.
> 
> <snip>
> 
> > Links is event based and almost all the code runs from event_loop. Will 
> > you fix libevent to allow fork() from event handlers? Or do you insist 
> > that we can't call fork from an event handler and that some workaround in 
> > links has to be implemented?
> 
> Hm, thinking about this a little bit more and I'm realizing that that
> patch was a mistake (and my thoughts about event_reinit() do not handle
> signal pipe reinit gracefully, was wrong), thanks for the report!
> 
> So I'm going to revert, but first I want to receive an answer to [1]
> (going to wait just for a couple of days, not more).
> 
>   [1]: https://github.com/libevent/libevent/pull/833#issuecomment-526375430
> 
> P.S. and this revert will be backported to the 2.1 tree and the next
> release will contain this patch.
> 
> Regards,
> Azat.

OK, so I will just add a code that blacklists version 2.1.11 and assume 
that all the following versions will be ok.


BTW - I'd like to ask - is it OK to call event_base_free from the libevent 
callback after fork? (assuming that we never return back to the callback)

I want to avoid leaking file descriptors to external programs started by 
links - so in the forked child I call event_reinit(base) and 
event_base_free(base) just to clean the open file descriptors. Is it OK or 
is it unsupported?

Mikulas
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.