Ah, here is the key info from Kernel.fork:
"The thread calling fork is the only thread in the created child
process. fork doesn‘t copy other threads."
So the @worker and started? methods in Merb::Worker are misleading
when in a child: the thread is dead.
Here is what Merb::Worker looks like in the child just after a fork:
#<Merb::Worker:0x37ca9a4 @thread=#<Thread:0x37ca88c dead>>
Here is my fix (a little ugly because of the need to nuke the
singleton) that is the simplest possible patch to get me unblocked:
merb-core/rack/adapter/abstract.rb:
def self.spawn_worker(port)
worker_pid = Kernel.fork
+ unless Merb::Worker.start.thread.alive?
+ Merb::Worker.instance_eval("@worker = nil")
+ Merb::Worker.start
+ end
...
You'll probably want to abstract the code into
Merb::Worker.alive?
and
Merb::Worker.restart
so that the code then reads
Merb::Worker.restart unless Merb::Worker.alive?
-Gary
On Jan 1, 9:34 am, Martin Gamsjaeger <[email protected]> wrote:
> Gary,
>
> This is a known bug that also affects merb/master. I'm not really
> familiar with those parts of the code, but here's a excerpt from a
> conversation with someone on irc who summarized it as follows:
>
> "The background worker is started after you fork the spawner, but
> before you fork workers so, although the workers each have their own
> work_queue (which is getting filled up), none of them have a
> background worker thread to process the queue."
>
> A patch for that would be highly appreciated :)
>
> snusnu
--
You received this message because you are subscribed to the Google Groups
"merb" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/merb?hl=en.
