X-Spam-Check-By: sourceware.org Date: Thu, 8 Jun 2006 22:03:58 -0400 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: cygwin non-posix problems Message-ID: <20060609020358.GA5641@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4485E5F3.7010700@tlinx.org> <20060607062254.GB2592@efn.org> <4488B498.4030306@tlinx.org> <45640.38.112.225.178.1149811889.squirrel@38.112.225.178> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45640.38.112.225.178.1149811889.squirrel@38.112.225.178> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote: >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. Indeed, this is standard operating procedure for debugging problems. >> 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. That would suggest that File::BOM is using blocking windows calls directly somehow. Gee, if only there was some way to narrow this down. I know! It must be because fork doesn't work on a multi-threaded dual core processor! cgf -- 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/