Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Gustaf Neumann]

Am 12.04.10 18:30, schrieb Stephen Deasey:
 Actually this doesn't make any sense and shows how long it's been
 since I've touched any C.


i haven't found any manpage where accepts results different errors than -1.

 But, i got that sucker: In the following ioctl (and others
 maybe as well) the long is wrong, since linux expects
 there an int.  That's why we see the problem with 64bit
 machines and on bsd!
  
 Well spotted.

 Does anyone know, how to figure out, on which platforms
 the long is wanted? The majority seems to be int.
  

 Not sure. Just go with int? How many people are running on MKS or Amiga?

replaced 2 occurrences of the problem with int
and undid the first fix.

Best regards
-gustaf neumann


--
Download Intel#174; 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

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Stephen Deasey]

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#174; 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