Thanks BrowserUk, corion and sundialsvc4 for the interesting discussion!

(I can not follow all the implementation details.) The discussion has made me aware of that there are many things to consider to write portable Perl code. Portability issues are dealt with in separate documents or sections and this make programmers working on the reference platform (Unix/Linux) less aware of problems in other platforms.

PROPOSAL

To add information about portability issues in the "Alphabetical Listing of Perl Functions" in perlfunc.

This can be done by at the end of function descriptions adding links to the the corresponding entry in "Alphabetical Listing of Perl Functions" in perlport.

UNPREDICTABLE RESULT OF KILL ON PSEUDO-PROCESS

Observations

1) This always blocks in Windows 7, but not on Windows 2000:

perl -e "if ($pid=fork){kill(9, $pid);} else {sleep 1000 }"

2) This sometimes blocks and sometimes gives the wrong exit value 9 in Windows 7:

perl -e "if ($pid=fork){Win32::Sleep(0); kill(9, $pid);} else {sleep 1000}"

3) Running this batch file a number of times on Windows 7:

@echo off
set count=0
:loop
set /a count=%count%+1
echo Count %count%
@echo on
perl -e "if ($pid=fork){Win32::Sleep(0); kill(9, $pid); Win32::Sleep(0
+)} else {sleep 1000}"
if errorlevel 1 goto exit
@echo off
goto loop
:exit
ECHO.%ERRORLEVEL%
[download]

gave the results:

• Perl is blocked after between 30 to several thousand loops.
• Sometimes perl exits with the wrong exit value 9.
• One time using the same command window for more than 20 times, perl exited all the times after less the 10 loops with the wrong exit value 9. Is there a missing initialization in the Perl (or Windows) implementation?

4) The installations of module on Windows 7 using install in cpan frequently hangs in the tests.

Conclusions and implications

There seem to be a Perl portability problem between different versions of Windows

If a test uses kill on a pseudo-process, the test must be run many times to detect the infrequent errors. It is not enough to run a test one time.

There is problems to install modules using Windows 7 and Strawberry Perl. Cpan install blocks and the installation has to be restarted.

A better way to inform about the problem?

I tried to describe the problems above with:

The outcome of kill on a pseudo-process is unpredictable.
It depends on the timing in the Windows operating system.
Code that has worked, suddenly can fail, resulting in errors which are
+ difficult to find.
[download]

My intention was do describe the consequence of the implementation (as opposed to describe the implementation and forcing the Perl programmer to draw the conclusions).

How can this be stated in a better way?

CAN WARNINGS BE USED TO IMPROVE PORTABILITY?

A way to support creation of more portable code could be to extend the "Perl Lexical Warnings" system, with optional warnings given when non portable Perl functions (and other non portable constructs) are used. Is this a feasible way to go?

OBSERVATIONS and OTHER THOUGHS

The discussion indicates that to write good Perl code you need to know Perl, the implementation of Perl and the underlying operating system. To write portable Perl code you need also to know the Perl implementation in all used platforms and in the underlying operating systems.

This puts very high demands on Perl programmers supposed to create portable modules and programs!

How is portability solved in Python and other dynamic languages? Can "Perl" learn something?