From: "Lin Jen-Shin (godfat)" <godfat@godfat.org>
To: Eric Wong <e@80x24.org>
Cc: yahns-public@yhbt.net, wildjcrt@gmail.com
Subject: Re: What would happen if a worker thread died?
Date: Sat, 9 May 2015 01:36:06 +0800 [thread overview]
Message-ID: <CAA2_N1ueSZ26i+FinfDvH8sWLVYg_adr1qp7qiK4uP+ORhfsOA@mail.gmail.com> (raw)
In-Reply-To: <20150508170311.GA1260@dcvr.yhbt.net>
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,
next prev parent reply other threads:[~2015-05-08 17:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 12:20 What would happen if a worker thread died? Lin Jen-Shin (godfat)
2015-05-08 17:03 ` Eric Wong
2015-05-08 17:36 ` Lin Jen-Shin (godfat) [this message]
2015-05-09 1:03 ` Eric Wong
2015-05-09 7:26 ` Lin Jen-Shin (godfat)
2015-05-09 8:47 ` Eric Wong
2015-05-09 9:03 ` [PATCH] worker threads log LoadError and SyntaxError, too Eric Wong
2015-05-09 9:06 ` What would happen if a worker thread died? Lin Jen-Shin (godfat)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/yahns/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA2_N1ueSZ26i+FinfDvH8sWLVYg_adr1qp7qiK4uP+ORhfsOA@mail.gmail.com \
--to=godfat@godfat.org \
--cc=e@80x24.org \
--cc=wildjcrt@gmail.com \
--cc=yahns-public@yhbt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/yahns.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).