httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@ibm.net>
Subject Re: cvs commit: apache-2.0/src/main http_log.c
Date Wed, 21 Jun 2000 18:01:11 GMT
> From: "Brian Havard" <brianh@kheldar.apana.org.au>
> Date: Thu, 22 Jun 2000 00:26:51 +1000 (EST)
> 
> On Wed, 21 Jun 2000 07:57:14 -0400, Jeff Trawick wrote:
> 
> >> From: "Brian Havard" <brianh@kheldar.apana.org.au>
> >> Date: Wed, 21 Jun 2000 19:00:03 +1000 (EST)
> >> 
> >> On Tue, 20 Jun 2000 19:05:37 -0700 (PDT), rbb@covalent.net wrote:
> >> 
> >> >> Good try but this won't work. The pipe must always be created non-blocking
> >> >> (else the DosConnectNPipe() blocks forever) & can stay that way.
OS/2
> >> >> allows attaching an event semaphore to the pipe which is triggered
when
> >> >> data is available. The parameters to the call to wait on that semaphore
> >> >> determine the block/non-block/timeout behaviour.
> >> >
> >> >Can we just create it non-blocking and use a -1 timeout value on OS/2?
> >> 
> >> Yep, exactly.
> >
> >I understand I need to back out the change to ap_create_pipe(), but
> >there is something that is still bothering me about
> >ap_set_pipe_timeout()...
> >
> >Your old ap_block_pipe() truly made the pipe blocking; it didn't
> >simply set the timeout to -1.  Why the discrepancy, and shouldn't I
> >back out the changes to ap_set_pipe_timeout() also, so that the pipe
> >is always non-blocking but your logic in ap_read() does the right
> >thing based on the value of timeout?
> 
> ap_read() will work either way, in fact thinking about it, it would be a
> little faster if actually set to blocking mode as it doesn't have to mess
> with the semaphore at all. It only waits on the semaphore if the read
> returns ERROR_NO_DATA (like EAGAIN/EWOULDBLOCK). I don't know if it would
> make a significant difference though, only some benchmarking would tell.

Hopefully this change to the current state of CVS fixes problems I
introduced as well as makes it work a little faster (as you describe
above).  It also fixes a glitch where setting pipe timeout to an
invalid negative value returned APR_SUCCESS.

We leave the pipe blocking after ap_create(), but it is non-blocking
during the DosConnectNPipe() call.

The pipe is set non-blocking if ap_set_pipe_timeout() is called with
timeout >= 0.  The pipe is set blocking if called with timeout -1.

Is this o.k. now?

Index: src/lib/apr/file_io/os2/pipe.c
===================================================================
RCS file: /cvs/apache/apache-2.0/src/lib/apr/file_io/os2/pipe.c,v
retrieving revision 1.22
diff -u -r1.22 pipe.c
--- pipe.c	2000/06/20 19:36:21	1.22
+++ pipe.c	2000/06/21 18:00:39
@@ -68,7 +68,7 @@
     char pipename[50];
 
     sprintf(pipename, "/pipe/%d.%d", getpid(), id++);
-    rc = DosCreateNPipe(pipename, filedes, NP_ACCESS_INBOUND, 1, 4096, 4096, 0);
+    rc = DosCreateNPipe(pipename, filedes, NP_ACCESS_INBOUND, NP_NOWAIT|1, 4096, 4096, 0);
 
     if (rc)
         return APR_OS2_STATUS(rc);
@@ -101,6 +101,10 @@
 
     rc = DosSetNPipeSem(filedes[0], (HSEM)(*in)->pipeSem, 1);
 
+    if (!rc) {
+        rc = DosSetNPHState(filedes[0], NP_WAIT)
+    }
+
     if (rc) {
         DosClose(filedes[0]);
         DosClose(filedes[1]);
@@ -146,13 +150,12 @@
 {
     if (thepipe->pipe == 1) {
         thepipe->timeout = timeout;
-        if (thepipe->timeout == 0) {
+        if (thepipe->timeout >= 0) {
             return APR_OS2_STATUS(DosSetNPHState (thepipe->filedes, NP_NOWAIT));
         }
         else if (thepipe->timeout == -1) {
             return APR_OS2_STATUS(DosSetNPHState (thepipe->filedes, NP_WAIT));
         }
-        return APR_SUCCESS;
     }
     return APR_EINVAL;
 }


-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message