Re: cvs commit: apache-apr/apr/file_io/unix filedup.c

[Brian Havard <br...@kheldar.apana.org.au>]

On 22 Apr 1999 19:21:00 -0000, rbb@hyperreal.org wrote:

>rbb         99/04/22 12:20:59
>
>  Modified:    docs     fileio.txt
>               include  apr_file_io.h
>               apr/file_io/unix filedup.c
>  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.

--
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------

Re: cvs commit: apache-apr/apr/file_io/unix filedup.c

[Ryan Bloom <rb...@raleigh.ibm.com>]

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