Re: lua-ev vs. fork

[Alexander Gladysh <agladysh@...>]

>>>> 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.

Alexander.