linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).