Re: lua-ev vs. fork

[Brian Maher <brimworks@...>]

BTW, the fix has been pushed to github:

http://github.com/brimworks/lua-ev/commit/e9565f94e8a42b49d8e107abeffad623c69a002e

Thanks,
-Brian

On Fri, Apr 23, 2010 at 6:55 AM, Brian Maher <brimworks@gmail.com> wrote:
> [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 <<
>



-- 
Brian Maher >> Glory to God <<