Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAPHN3JXjkVf5cJZtSW2JZT+OjD5Qf12nZb0VLNavKCXAf9h5+A@mail.gmail.com>
References: 
 <CAPHN3JW+ycf1+DdPwM2XWHqYBYiA4KH3N9Pu-p3ZY+wq2cfrgg@mail.gmail.com>
	<CAHB0tE7wng5h=haygrZP-94=Js4K=cKH9CaJZBmnvLM0A9EZNg@mail.gmail.com>
	<CAKUrXK6+MJtwRvCX4jJfnjwhoXfCZkkQ-R3fA9z7xLv5ZLBmcA@mail.gmail.com>
	<CAPHN3JXjkVf5cJZtSW2JZT+OjD5Qf12nZb0VLNavKCXAf9h5+A@mail.gmail.com>
Date: Wed, 6 Jul 2011 09:20:28 +0200
Message-ID: 
 <CAPHN3JXFZrJfVYpVRjHfc7iwjo+2UtfVR8ZJ-SxCOqSFmx0Uow@mail.gmail.com>
Subject: Re: Graceful server shutdown?
From: Antonio Vieiro <antonio@antonioshome.net>
To: dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all again,

I've noticed high CPU usage, and the fact is that there's a problem
with accept and socket timeouts and my code.

I'll review http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutoria=
l-13.html#ss13.4
and will post a correct code later on, just for the records.

Cheers,
Antonio

2011/7/6 Antonio Vieiro <antonio@antonioshome.net>:
> Thanks guys, that's the approach I am following. The accept loop looks
> something like:
>
> apr_socket_opt_set(server_socket, APR_SO_NONBLOCK, 1);
> apr_socket_timeout_set(server_socket, 100);
> ...
>
> while (!server_stop) {
> =A0do {
> =A0 =A0status =3D apr_socket_accept(&client_socket, server_socket, server=
_pool);
> =A0} while (!server_stop && APR_STATUS_IS_EAGAIN(status));
> }
>
> And the signal handler just sets the "server_stop" flag to some non-zero =
value.
>
> This works fine on a Windows box, I'll try to see how well it behaves
> on a Unix box later on, and will post here just for the record.
>
> Thanks,
> Antonio
>
> 2011/7/5 Jeff Trawick <trawick@gmail.com>:
>> On Tue, Jul 5, 2011 at 11:00 AM, Wes Garland <wes@page.ca> wrote:
>>>> On both cases I imagine the server cleanup (apr_pool_destroy) should
>>>> be performed after the server loop, and not in the signal handler,
>>>> right?
>>>
>>> Correct. Your signal handler should just set a flag and return.=A0 The =
list of
>>> functions which can be safely run from a signal handler is very short, =
and
>>> malloc/free are not among them.
>>>
>>>> b) Shall I set a "keep-running" flag (using mutexes, i.e, a
>>>> synchronized flag) for shutdown on the SIGINT handler?
>>>
>>> Not mutexes.=A0 There is no need and the pthread mutex functions (which=
 APR is
>>> implemented on top of on UNIX) are not async-signal safe.=A0 Here is my=
 basic
>>> pattern:
>>>
>>> int die =3D 0;
>>> int signalHandler(signal)
>>> {
>>> =A0 die =3D signal;
>>> }
>>>
>>> while (!die)
>>> {
>>> =A0 /* accept, fork */
>>> }
>>
>> Another piece of the puzzle is that APR on Unix can return EINTR
>> (signal interruption) from a few critical functions
>> (apr_socket_accept() and apr_poll*() and maybe something else), but
>> generally eats EINTR internally. This has an impact on when your main
>> thread gets to check the die flag.
>>
>> This is all rather non-portable. =A0(You can get WSAEINTR from
>> apr_socket_accept() on Windows but that means something totally
>> different.)
>>
>