[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua-ev vs. fork
- From: Alexander Gladysh <agladysh@...>
- Date: Fri, 23 Apr 2010 21:37:06 +0400
>>>> I suspect this is because luaopen_ev() has this line of code:
>>>> pthread_atfork(0, 0, ev_default_fork);
>>>> Perhaps ev_default_fork isn't working right?
>>> Perhaps. I also note that you do not call ev_loop_fork() for
>>> non-default loops. You probably should.
>> BTW, regarding that pthread dependency.
>> Consider exposing ev.at_fork() callback to user and creating a
>> separate, auxiliary Lua module which exposes pthread_atfork to Lua.
>> This way users, who do not need forking, would not have to pay for it. :-)
> I think the "cost" is very minimal. The only real "cost" (in my mind)
> is the currently required dependency on pthreads (the ev_default_fork
> function simply sets two variables). Ideally, at build time we would
> give people the option to build without pthreads in which case we
> print a loud warning that if you try to use the default event loop in
> a child process things may be messed up unless they call loop:fork().
Well, the cost is in build compexity as well.
For example, I do not think that you'll be able to build such option
into a rockspec file.
> I do think that a loop:fork() function should be exposed that either
> calls ev_loop_fork or ev_default_fork depending on if it is the
> default loop.
I'd prefer loop:at_fork(), I think it would be less confusing.
> To be honest, I'm still not sure what is "best". If we register an
> atfork handler for ev_default_loop then we might prevent users from
> "shooting themselves in the foot", but on the other hand it adds an
> extra dependency, and doesn't take care of the non-default loop
> cases... although it should be pointed out that there are certain
> limitations on non-default event loops.
I think that half-supporting a feature could be worse thank not
supporting it at all. :-)
A big warning in the README should deal with the most of foot-shooters.