Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 23250 invoked by uid 6000); 23 Apr 1999 11:37:58 -0000 Received: (qmail 23241 invoked from network); 23 Apr 1999 11:37:57 -0000 Received: from fwns2d.raleigh.ibm.com (HELO fwns2.raleigh.ibm.com) (204.146.167.236) by taz.hyperreal.org with SMTP; 23 Apr 1999 11:37:57 -0000 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA22870 for ; Fri, 23 Apr 1999 07:37:53 -0400 Received: from webdev7.raleigh.ibm.com (webdev7.raleigh.ibm.com [9.37.72.37]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA34114 for ; Fri, 23 Apr 1999 07:37:55 -0400 Date: Fri, 23 Apr 1999 07:27:19 -0400 (EDT) From: Ryan Bloom To: "new-httpd@apache.org" Subject: Re: cvs commit: apache-apr/apr/file_io/unix filedup.c In-Reply-To: <199904230327.NAA06015@silk.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org > > Log: > > A new file function to allow me to specify a file descriptor to be put into > > an apr_file. I am still trying to figure out if this needs to be abstracted > > more, and how to do it. But, the function is needed for the process stuff, > > so I am committing it now. > > > +apr_status_t apr_pushfile(apr_file_t *, int) > > + Push a platform specific file descriptor into the apr file type. > > + Arguments: > > + arg 1) the file descriptor to modify. > > + arg 2) The file descriptor to push. > > + return) APR_SUCCESS or APR_FAILURE > > The problem with that is that a file descriptor's type varies by platform. In > unix it may be an int but in OS/2 it's an unsigned long and in Win32 it's a > HANDLE (which is actually a void *). I don't know about BeOS or Mac. > > Maybe if you describe the problem you're trying to solve we can come up with > a suitable method. I knew this one wasn't going to fly. It's okay. I figured out how to solve the problem last night, so I will be removing this patch in a little while. I was trying to keep the process stuff in apr from knowing about the file_io stuff in apr, but I am reasonable convinced that isn't going to work very well. The basic problem is that I am creating a new process, and I need to be able to setup pipes to the new process, for stdin, stdout, and stderr. Those pipes are apr_file_t types, and I needed to dup2 the child's std* fileno to the apr_file_t, and this patch let me do this with an apr function. I don't think I need or want an apr function to do this though. What I want, is to have the apr_create_process function have access to the internals of apr_file_t for the platform it was written for. Does that make sense? Ryan _______________________________________________________________________ Ryan Bloom rbb@raleigh.ibm.com 4205 S Miami Blvd RTP, NC 27709 It's a beautiful sight to see good dancers doing simple steps. It's a painful sight to see beginners doing complicated patterns.