[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- 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
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.