Re: lua-ev vs. fork

[Alexander Gladysh <agladysh@...>]

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

See this discussion for example:

http://thread.gmane.org/gmane.comp.gdb.devel/24205

And this post in particular:

http://thread.gmane.org/gmane.comp.gdb.devel/24198/focus=24209

I'm actually bitten by this problem, my gdb refuses to debug lua
executable after I do 'require "ev"':

http://stackoverflow.com/questions/2702628/gdb-cannot-find-new-threads-generic-error

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

Alexander.