cygwin non-posix problems
Fri Jun 9 02:07:00 GMT 2006
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
>> 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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin