On Sun, Apr 11, 2010 at 4:16 PM, <commits-nore...@bitbucket.org> wrote:
>
> changeset: 2575:3963e46562e8
> user: Gustaf Neumann <neum...@wu-wien.ac.at>
> date: Sun Apr 11 17:16:27 2010 +0200
> summary: Fix to prevent multiple DriverAccepts on the same socket.
> The original coded relied on the fact that later accepts lead to
> an ERROR_STATE. Under RHEL 4 (Power, 64bit) the second accept
> blocks.
>
>
> diff --git a/nsd/driver.c b/nsd/driver.c
> --- a/nsd/driver.c
> +++ b/nsd/driver.c
> @@ -1523,7 +1523,22 @@ SockAccept(Driver *drvPtr, Sock **sockPt
> * Accept the new connection.
> */
>
> - status = DriverAccept(sockPtr);
> + /*
> + * Hmmm: the original implementation was written in style that
> + * DriverAccept was called twice, one to return for e.g. a simple,
> + * new HTTP request NS_DRIVER_ACCEPT (staying in the SOCK_MORE
> + * status), and then calling ACCEPT again, but which causes on our
> + * RHEL 4 system (POWER6, 64bit) a hang: the second accept blocks,
> + * while it returns under (most?) other system a
> + * NS_DRIVER_ACCEPT_ERROR. It seems that the original code rely on
> + * this ERROR handling. It is not clear to me, why the second call
> + * to ACCEPT is necessary, when the socket is already available.
> + */
> + if (*sockPtrPtr) {
> + status = NS_DRIVER_ACCEPT_ERROR;
> + } else {
> + status = DriverAccept(sockPtr);
> + }
>
> if (status == NS_DRIVER_ACCEPT_ERROR) {
> status = SOCK_ERROR;
> It is not clear to me, why the second call to ACCEPT is necessary, when the
> socket is already available.
http://bitbucket.org/naviserver/naviserver/src/tip/nsd/driver.c#cl-1175 :
DriverThread():
if (waitPtr == NULL) {
/*
* If configured, try to accept more than one request,
under heavy load
* this helps to process more requests
*/
accepted = 0;
while (accepted < drvPtr->acceptsize
&& drvPtr->queuesize < drvPtr->maxqueuesize
&& PollIn(&pdata, drvPtr->pidx)
&& (n = SockAccept(drvPtr, &sockPtr)) != SOCK_ERROR) {
switch (n) {
...
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
