[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua-ev vs. fork
- From: Alexander Gladysh <agladysh@...>
- Date: Sat, 24 Apr 2010 04:30:47 +0400
>>> 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.
Note also that Lua executable is not linked with pthreads. And some
tools (like gdb) do not like when program suddenly becomes
See this discussion for example:
And this post in particular:
I'm actually bitten by this problem, my gdb refuses to debug lua
executable after I do 'require "ev"':
And really want to report you a bug with hidden SIGSEGV that I observe. :-)
(Note that I need to be able to fork() properly to reproduce this bug,
so simply hacking out pthreads is not a solution — an at_fork()
callback is still needed.)