Indeed it seems that there is a problem with dup()'ing. I've seen the
same problem as Graham, when I'm running Apache::SubProcess
(mod_perl-2.0) tests with 5.6.1, sometimes the output is returned from
the subprocess, sometimes it is not.
In the code:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/xs/APR/PerlIO/apr_perlio.c?rev=1.20&content-type=text/vnd.viewcvs-markup
we handle differently < 5.6.1 and 5.8.0 (PERLIO_LAYERS). I've copied the
5.6.1 code from Doug's module and that's the one that loses output. In
the version that handles 5.8.0's IOLayers, I haven't dupped the PerlIO*
struct and it seems to work fine, though I've placed XXX there to verify
that this doesn't have any ill effects, which may happen if the timeout
happens and Apache decides to close the fh before the time.
Please look at the conversion functions at the end of the file namely
apr_perlio_apr_file_to_PerlIO and apr_perlio_apr_file_to_FILE. These
conversion functions are needed because Apache 2.0 is using an opaque
apr_file_t struct for handling file handles.
Graham Barr wrote:
> Ah, that would be a problem if Apache had a handler to close the FILE*
>
> As the handler is for the FILE* (I saw by reading the code) We could
> work around this by doing
>
> freopen("/dev/null",mode,fp);
>
> after the dup has been done. That would result in the FILE* apache
has a cleanup
> handler on still being valid, and only one fd open to the pipe to the
subprocess
I've tried to do that in the port that I did, but it didn't help.
> On Mon, Aug 19, 2002 at 09:43:39AM -0700, [EMAIL PROTECTED] wrote:
>
>>hi graham,
>>sorry for the delay. i haven't touched this module is so long, but recall
>>the dup is because apache registers a cleanup to close the file, so perl
>>needs its own copy. could be that there's a better way. you might want
>>to resend to [EMAIL PROTECTED], stas bekman has implemented the 2.0
>>version of this module and might have some more insight.
>>
>>On Fri, 19 Jul 2002, Graham Barr wrote:
>>
>>
>>>Doug, In SubProcess.xs you have
>>>
>>>static FILE *io_dup(FILE *fp, char *mode)
>>>{
>>> int fd = PerlIO_fileno(fp);
>>> FILE *retval;
>>>
>>> fd = PerlLIO_dup(fd);
>>> if (!(retval = PerlIO_fdopen(fd, mode))) {
>>> PerlLIO_close(fd);
>>> croak("fdopen failed!");
>>> }
>>>
>>> return retval;
>>>}
>>>
>>>I was wondering what the purpose was of the line
>>>
>>> fd = PerlLIO_dup(fd);
>>>
>>>I was having a problem with the spawned process seeing EOF, but
>>>if I removed this line then it saw it. So I was wondering if
>>>there was a specific reason you dup'd the fd.
>>>
>>>However, even though with this my code sees EOF. Sometimes it
>>>does not work. I have a script that does
>>>
>>> #!/usr/bin/perl
>>> open(STDERR,">/tmp/gmb");
>>> select STDERR;
>>> $|=1;
>>> warn "$$ $_\n" for @ARGV;
>>> while(<STDIN>) {
>>> warn $_;
>>> }
>>> warn "DONE";
>>>
>>>Most times in /tmp/gmb I see everything, but sometimes the file
>>>is empty. The fact it is there, but empty, makes me think the process
>>>gets killed, do you know if thats the case and why ?
>>>
>>>Regards,
>>>Graham.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
