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

2010-04-12 Thread 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

Re: [naviserver-devel] driver changes, please check

2010-04-12 Thread Stephen Deasey 
On Sun, Apr 11, 2010 at 4:42 PM, Gustaf Neumann neum...@wu-wien.ac.at wrote:

 PS: i had to do a hg push -f  Not sure, if this is intentional.
 Do the commits to tip look right?


All that's happened here is that you've made changes to your checkout
without first updating it. In the meantime, Zoran has made changes and
pushed them.

If this were CVS it would refuse to let you commit. With mercurial
obviously you can commit as it's local, but it will not let you push
and will give you a warning. You ignored the warning by using -f  :-)

You are going to have to merge the two heads with 'hg merge' and then
push that changeset. See: hg help merge.

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