Newsgroups: comp.lang.perl,comp.os.linux
Subject: PERL 4.035 almost ready for LINUX.
From: Greg Wettstein < NU013809@NDSUVM1.BITNET>
Date: Monday, 13 Jul 1992 09:01:01 CDT
Organization: North Dakota Higher Education Computer Network

Since it was time to upgrade PERL on our XENIX(c) platforms I decided to
bite the bullet and get it operational on LINUX since we will need it
there shortly as well.  I have PERL 4.035 at a point where it passes all
but one test.

Specifically it fails on test #8 in the io/pipe.t test.  Actually the
testing routines report the failure on test 8 but it is actually test 7
which is the culprit.  Test 7 involves the use of $SIG{"PIPE"} to set
an exception handler up for a broken pipe.  The code in the exception
handler is executed when a write to the pipe with one end closed is
executed but execution does not return to the instruction after the
write.  The script fails with a Broken Pipe message from the operating
system and execution terminates.

I know that the signal handling available on LINUX takes two forms, one
which follows the classic use of signal and the other which installs
exception handlers via the sigaction mechanism.  From my understanding the
signal installed handlers are one-shot exception handlers while those
of the sigaction variety will be called repeatedly.  Beyond this my
understanding in this area is very limited.  I do not know if this is the
root of the problem and would appreciate any comments that the two groups
may have.

I will upload a binary PERL package to banjo if I can get it to pass all
tests, that is if someone doesn't beat me to the punch.  Incidentally as
a point of interest it does not appear that LINUX allows PERL to change
back to its original uid once a change from the original uid is made.
This shows up in the op/stat.t test as a failure in test #18.  The
actual point of failure is in tests 9 and 10 when uid changes are
executed.  This may be a configuration error on my part but I have not
looked into this issue once I figured out what was happening.

Any information which may be helpful would be appreciated.  Please use
the address in my .sig and thanks in advance for any comments.

                            As always,
                            Dr. G.W. Wettstein
                            Oncology Research Division Computing Facility
                            Fargo Clinic / MeritCare

                            UUCP: uunet!plains!wind!greg
                            INTERNET: greg%wind.uucp@plains.nodak.edu
                            Phone:  701-234-2833

`The truest mark of a man's wisdom is his ability to listen to other
 men expound their wisdom.'

Newsgroups: comp.os.linux
From: jrs@world.std.com (Rick Sladkey)
Subject: Re: PERL 4.035 almost ready for LINUX.
In-Reply-To: Greg Wettstein's message of Monday, 13 Jul 1992 09:01:01 CDT
Organization: The World
Date: Wed, 15 Jul 1992 01:27:32 GMT

>>>>> On Monday, 13 Jul 1992 09:01:01 CDT, Greg Wettstein
>>>>> < NU013809@NDSUVM1.BITNET> said:

Greg> Specifically it fails on test #8 in the io/pipe.t test.
Greg> Actually the testing routines report the failure on test 8 but
Greg> it is actually test 7 which is the culprit.  Test 7 involves the
Greg> use of $SIG{"PIPE"} to set an exception handler up for a broken
Greg> pipe.  The code in the exception handler is executed when a
Greg> write to the pipe with one end closed is executed but execution
Greg> does not return to the instruction after the write.  The script
Greg> fails with a Broken Pipe message from the operating system and
Greg> execution terminates.

I sent a kernel patch in for a different problem with the same test a
little while ago and perl then passed the pipe tests with GCC 2.11c.
Now it is fails due to a new bug in the iostream stdio library.  The
problem is that when the output is flushed or the file pointer is
closed, iostream keeps trying to write out the data in its buffer even
after an error (SIGPIPE) occurred when trying to write it the first
time.

I suppose this behavior is a matter of opinion but since our perl
fails I would suspect that most versions of Unix advance the buffer
pointer past the written data when a write error occurs.  There is
little you can do to fix it without rebuilding the libraries yourself.

Per Bothner, who wrote iostream, may be reading this, and if he
concurs, may change it for the next release of GCC.
--
Rick Sladkey
jrs@world.std.com