Michael G Schwern wrote:
On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote:
Test 7 is failing because normally on VMS, unless you specify otherwise,
you get exclusive access to the file, so the second open is failing.
The logical name DECC$FILE_SHARING defined as "ENABLE" will change VMS
behavior to that of UNIX which will allow test 7 to pass.
I can probably come up with some code to have the script on VMS make
sure that that value is set and to clear it on exit.
Test 8 is more of a problem. The issue is that the buffers for the
other stream written by the new_tb->output("some_file") have not made it
to disk, so they can not yet be read by the new input stream to pass the
test.
There does not seem to be a method of explicitly closing or flushing the
output stream being written to by Test::Builder.
I was about to commit the test fix for this and then I realized that
Test::Builder unbuffers its newly created output filehandles. Everything
should be written to disk immediately. If not then there's a bug either
in Test::Builder's autoflush logic or in Perl.
Could you have another look at this? Test::Builder _new_fh() and _autoflush()
will be of some interest.
_autoflush is setting $| which should cause a flush.
The only call to fsync() that I can find that gets compiled in on the
VMS build is in vms/vms.c routine Perl_my_flush() which has a macro
alias of my_flush(), and a macro alias Fflush().
Setting a breakpoint on vms/Perl_my_flush() on the debugger shows that
it is not called, and this is the only way that the I/O will be written
to disk.
Putting a break on pp_hot/Perl_pp_print() shows that it recognizes that
the $| variable was set, and it calls PerlIO_flush.
PerlIO_flush looks up a function in a table and ends up calling
PerlIOBuf_flush().
PerlIOBuf_flush() writes the internal buffer to the C library internal
buffer.
It then calls PerlIO_flush again and this time the function lookup is to
a routine that does nothing by design.
Nothing ever called an fsync() call, so nothing is guaranteed to get to
the disk.
It seems to work ok flushing I/O to the terminal.
A scan of the source code shows that my_flush or Perl_my_flush is only
referenced in VMS.C
Fflush is only referenced in ext/IO/io.c, and an alias of PerlSIO_fflush.
It appears that that PerlSIO_fflush() is called by PerlIOStdio_flush() only.
So it appears the problem is that nothing is calling fsync(), but I am
not sure what needs to be changed to fix this. I also do not know if
this affects anything other than VMS.
-John
[EMAIL PROTECTED]
Personal Opinion Only
