delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/06/08/19:37:41

X-Spam-Check-By: sourceware.org
Message-ID: <4488B498.4030306@tlinx.org>
Date: Thu, 08 Jun 2006 16:36:56 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin non-posix problems
References: <4485E5F3 DOT 7010700 AT tlinx DOT org> <20060607062254 DOT GB2592 AT efn DOT org>
In-Reply-To: <20060607062254.GB2592@efn.org>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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


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.

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.

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

linda






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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019