Re: lua-ev vs. fork

[Brian Maher <brimworks@...>]

[Sorry, the last email didn't get sent to the lua list because I used
my brian@brimworks.com address... I've tried updating the lua mailing
list to use that address but for some reason I never get the
confirmation emails]

To recap my last email:

  * If you posix.wait(pid) and print the results you will see "what
happened to the child".
  * If you instantiate the default event loop by using it (something
like ev.Loop.default:loop()), then everything works.  So, this is a
bug in lua-ev that I'll fix ASAP.

Response inline...

On Fri, Apr 23, 2010 at 4:14 AM, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 14:42, Alexander Gladysh <agladysh@gmail.com> wrote:
>> On Fri, Apr 23, 2010 at 07:28, Brian Maher <brian@brimworks.com> wrote:
>>> 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().

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.

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 need to think about this some more :-(.

Thanks,
-Brian

>
> Alexander.
>



-- 
Brian Maher >> Glory to God <<