X-Spam-Check-By: sourceware.org
Message-ID: <45640.38.112.225.178.1149811889.squirrel@38.112.225.178>
In-Reply-To: <4488B498.4030306@tlinx.org>
References: <4485E5F3 DOT 7010700 AT tlinx DOT org> <20060607062254 DOT GB2592 AT efn DOT org>     <4488B498 DOT 4030306 AT tlinx DOT org>
Date: Thu, 8 Jun 2006 17:11:29 -0700 (PDT)
Subject: Re: cygwin non-posix problems
From: "Yitzchak Scott-Thoennes" <sthoenna AT efn DOT org>
To: cygwin AT cygwin DOT com
User-Agent: SquirrelMail/1.5.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Linda Walsh wrote:
> Yitzchak Scott-Thoennes wrote:
>> Can he or you reduce the problem to a non-File::BOM dependent test
>> script
> What part of the perl module File::BOM should I throw out before
> it's no longer File::BOM?  It's just perl code.
>
> It's freely downloadable through CPAN, so I can't make it too
> much more publicly available than that.

The point would be to reduce the amount of code that might need
to be inspected to find the underlying problem.  Nothing to do
with publicly available.

> But FWIW, the File::BOM code isn't the actual problem.  It's
> the authors test routine that he decided to be "fancy" with,
> and use a child process to send strings via a "FIFO" to the
> test harness process.
>
> It isn't desirable to modify "cygwin-only-failing" Perl modules
> to work around problems than only happen under cygwin.  Certainly
> you can see how that is "burying one's head under the sand".  Suppose
> various parts of CPAN are rewritten to steer around bugs in Cygwin.
> Does that make the underlying problems problems in Cygwin go away?
> Does that make cygwin more stable or more compatible with other
> Posix platforms?
>
> In my mind it eliminates test cases that are perfectly uncovering
> Cygwin incompatibilities and deficiencies.

I agree with all of the above and wasn't trying to suggest modifying
the tests.

> Another example is the Win32::API module?  It also
> fails under cygwin -- starting about 9 months ago.  Still does.  The
> problems in cygwin aren't going away.  And when module developers
> get bugs reported under cygwin, they may not bother with them if
> cygwin is known to have many Posix compatibility problems.

I didn't know posix compatibility problems were at issue there?
And I don't think posix compatibility ranks high in importance
for Win32::API.

> The module maintainers would like nothing more than for their module
> to work w/o problems on all platforms.  Perl goes to great lengths
> to ensure "it just works", "out-of-the-box" on scores of platforms.
>
> Also, FWIW, I did report a simpler test case that came up during
> their continued attempts to isolate the problem:
> ([perlbug #39325]: Cygperl allows reading of file descriptors open
> Write-Only)
>
> I don't know if the above bug is somehow the "root" cause of the
> problem in File::BOM but I doubt it is solely responsible for the
> behaviors I'm seeing, including cygperl hanging and being
> unkillable from within cygwin.
>
> Certainly, we can agree, that a process under cygwin should not
> normally hang and be unresponsive to cygwin "kill -9" signals?

/bin/kill -f worked for me.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/