From: Dallas Clement <dallas.a.clement@gmail.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: Slow signal delivery to server process with heavy I/O
Date: Sat, 10 Jul 2010 18:46:58 -0500 [thread overview]
Message-ID: <AANLkTim5E9FROyVQJceAD-xNA2JJS0MsjQpY8j73bmdN@mail.gmail.com> (raw)
In-Reply-To: <AANLkTin9wvP1p3rp3Lv6-APEfvq9jZACF0TEas9a2f6l@mail.gmail.com>
Yes, I have tried setting this flag. Doesn't seem to make any
difference. My main thread doesn't do much. He registers for the
signal and then waits on a self-pipe and wakes up when a signal
arrives. All the I/O action is happening in the other threads. I'm
not expecting the other threads to be interrupted during a system call
like 'select', 'send', 'recv' etc, but even if they were, they detect
EINTR and try again.
On Sat, Jul 10, 2010 at 6:26 PM, Gao Free_Wind <gfree.wind@gmail.com> wrote:
> Do you set the SA_RESTART flag for the signal?
> If set SA_RESTART flag, it will restart the system calls include I/O.
>
> On Sat, Jul 10, 2010 at 4:08 PM, Dallas Clement <dallas.a.clement@gmail.com>
> wrote:
>>
>> Hi All,
>>
>> I've noticed that asynchronous signals such as SIGINT, SIGTERM etc are
>> delivered to my process long after the signal is sent if the receiving
>> process is handling lots of I/O. My process is a multi-threaded web
>> server. It's got one thread waiting on 'select' to accept incoming
>> connections and a thread pool which reads the data with 'recv'.
>>
>> When I batter the web server with incoming traffic and I try to
>> shutdown the server by sending a SIGINT or SIGTERM, I have observed
>> that the web server finishes handling the incoming traffic before the
>> kernel dispatches the signal to the process. It appears that the
>> 'select' and 'recv' calls are getting highest priority with regard to
>> scheduling.
>>
>> I realize this test may appear unnatural and is perhaps unrealistic,
>> but I would like to be able to shutdown my server gracefully within a
>> reasonable amount of time, no matter what kind of load it is handling.
>> Don't want to have to wait several minutes for my signals to get
>> handled under heavy load. Could someone please explain why signal
>> delivery is slow under these conditions?
>>
>> Thanks in advance,
>>
>> Dallas
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-c-programming" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-07-10 23:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-10 23:08 Slow signal delivery to server process with heavy I/O Dallas Clement
[not found] ` <AANLkTin9wvP1p3rp3Lv6-APEfvq9jZACF0TEas9a2f6l@mail.gmail.com>
2010-07-10 23:46 ` Dallas Clement [this message]
2010-07-11 13:18 ` Glynn Clements
2010-07-11 22:56 ` Dallas Clement
2010-07-12 2:48 ` Glynn Clements
2010-07-12 7:06 ` ern0
2010-07-12 16:14 ` Glynn Clements
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTim5E9FROyVQJceAD-xNA2JJS0MsjQpY8j73bmdN@mail.gmail.com \
--to=dallas.a.clement@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
/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.
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 NNTP newsgroup(s).