Re: What would happen if a worker thread died?

["Lin Jen-Shin (godfat)" <godfat@godfat.org>]

On Sat, May 9, 2015 at 1:03 AM, Eric Wong <e@80x24.org> wrote:
> "Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> Ugh, I guess since it happened in a thread, the error message got
> swallowed unless you were running in $DEBUG.

I like the idea of setting $DEBUG, however it's too noisy given
current state :( See how many messages got printed with this:

$ ruby -dS gem list > /dev/null

> Loading code after the server is ready and serving requests is a bad
> idea.  It leads to really nasty thread-safety problems as well as
> invalidating the method/constant caches.

Yeah, I did that in the first place because I don't want my runtime
being polluted with those methods from activesupport. However at
some point we just need to use some stuffs from activesupport
in some cases. Therefore I put those requires in that particular
method. Only a few cases it would be used, that's what I was thinking.
But eventually it got triggered from some unexpected places.

Now it's removed and replaced with codes copied directly from
activesupport. No activesupport and requires need now.

>> When this happened, the client just hanged forever with yahns.
>> Is there something we can do about this? Would yahns respawn
>> a new worker thread? Can we close the socket when this happen?
>
> It's unfortunately difficult to detect thread death from ruby (no
> SIGCHLD handler unlike for processes) besides polling Thread#join
>
> We had this issue in ruby-core a few years back, but apparently
> it was forgotten/ignored by matz.  Care to chime in?
> https://bugs.ruby-lang.org/issues/6647

I just sent a few characters, hope that would speed up the process.

>> I am aware that yahns is *extremely sensitive to fatal bugs in the
>> applications it hosts*, so I am just curious.
>>
>> For reference, Puma would immediately close the socket without
>> sending anything, and Unicorn would log the error backtrace and
>> kill the worker (If I read it correctly).
>>
>> In this case, Unicorn helped me figure out what's happened.
>
> yahns can probably rescue Exception (or Object(!) like puma)
> and then log + abort the entire process.

I think rescuing Object is misleading. AFAIK, we cannot raise
an instance which is not a kind of Exception.

I learned that rescuing Exception is a bad idea because like
signal handling and some other stuffs are also using Exception
to communicate, and of course we won't want to interfere.

However for a worker thread, I guess that might be ok?

Cheers,