cygwin fork problem maybe?

[Linda W <perl-diddler at tlinx dot org>]

A problem I reported in trying to install "File::BOM" (module to handle files 
with Unicode Byte-Order-Marks) under CPAN originally here:
http://sourceware.org/ml/cygwin/2006-02/msg00238.html last February
is still a problem.  I bounced it off of the module maintainer, and he
believes the problem has to do with "forking", not FIFO use.

His test works under AS Perl, but he doesn't think he'll be able to
get his module to work under cygwin with these problems.

A summary snippet of the last email I got from him is included below.

The symptoms of the hung processes are still the same -- both instances
of perl running the test completely lock-up and are unkillable in the cygwin
environment

Is there any chance of getting someone to look at this problem?

I'm rather depressed at the number of Win32 modules that don't work under
cygwin.  I know this may be considered a "feature" by some, but if I wanted
a POSIXish environment that was incompatible with Win32, I'd run linux, but
I want a *nix environment that lets me access the native system's
features.  If it was only a few Win32 modules that had problems, that'd be
one thing, but I feel overwhelmed by the number of incompatibilities.

Anyway I didn't know fork was such a problem on Windows...

thanks for any help on this...
-linda



-------- Original Message --------
Subject: Re: [perl #39211] cygperl hangs on FIFO use (attempt install of CPAN 
File::BOM hangs during test using FIFO)
Date: Tue, 06 Jun 2006 12:18:09 +0100
From: "CPAN File::BOM module maintainer"

...
I would say it's definitely fork() that's the problem, not fifo support.
...
For what it's worth, the tests succeed on ActivePerl.


> > I know that fork is a bit of a bugbear for the activeperl team. forking
> > on win32 is probably always going to be a problem. *sigh*
>     ... 
Windows just doesn't support forking at all, as far as I know.
activeperl emulates forking using win32 threads. I don'tknow how cygwin
handles it, but my guess is that it's not very well :-(



> > Those exception test results seem to indicate that there's no problem
> > reading from filehandles that were opened for writing, or even reading
> > from non-existent files.
...

The tests that are failing are these:
    open WRITER, '>', $tmpfile or die "Couldn't write to '$tmpfile': $!";

    throws_ok { File::BOM::_get_encoding_seekable(\*WRITER) }
	    qr/^Couldn't read from handle/,
	    "_get_encoding_seekable on unreadable handle fails";

    throws_ok { File::BOM::_get_encoding_unseekable(\*WRITER) }
		qr/^Couldn't read byte/,
		"_get_encoding_unseekable() on unreadable handle fails";


The first one, at least, returns normally, which indicates that
it succeeded in reading from the WRITER handle, which was
opened for writing.

One of the other failing tests tried to
read from a generated (non-existent) tempfile name, and also didn't die.

...

I don't think I'm going to be able to fix the tests to pass on cygwin,
other than testing $^O and skipping all forking and exception tests,
which seems a bit like cheating.

--------



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