BrowserUk, thank you! I appreciate your straightforward answers.

Sorry n'all, but that is garbage! Whilst you may have seen some symptoms like these and have attributed them to the use of signals; I'll bet that you cannot post code to demonstrate it.

This is a case of, as I believe, an inappropriate usage of signals, and the related symptoms of system degeneration. It is from https://rt.cpan.org/Public/Bug/Display.html?id=66437

I am using:

• Strawberry-perl-5.12.2.0
• Perl 5, version 12, subversion 2 (v5.12.2) built for MSWin32-x86-multi-thread
• Windows 7 Home Premium with Service Pack 1

I have used version 1.11 and 1.12 of Test::TCP.

Problem: The test in Test::TCP is blocking. Get the system in state, that it must be restarted. It is sometimes not possible to kill the blocked processes. I even get errors like “Can't spawn "cmd.exe"” when using the system call. It indicates a degeneration of the perl interpreter.

One example of stochastic behavior (from https://rt.cpan.org/Public/Bug/Display.html?id=66016) is running this batch file:

@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]

Examples of results I got was:

• Blocking after 38 to 2806 loops.
• Running more than 7000 loops.
• Exiting with the value 9 after 1-7 loops.

This was done using Strawberry-perl-5.12.2.0. The patch http://perl5.git.perl.org/perl.git/commitdiff/82e24582 removed most of the problem but not all. It was also found that version of the Windows operating system had different behavior.

As for the rest: Unix Signals are (one of several) "Unfixable designs". And most all the caveats and warnings you quoted from the MS docs for TerminateThread() are equally applicable to causing any piece of code to be interrupted without resumption using a longjump. Ie. Signals.

As an IPC mechanism, that only conveys 1 bit of information and is edge triggered -- ie. missable unless you happen to be ready for them -- signals are a piss poor substitute for proper IPC mechanisms.

And the need to use them to abandon in-progress processing is a sign of badly designed code. Describe the use case for using them and I'll outline a better way of tackling the problem. (Though it may or may not be currently available from Perl.)

I interpret your standpoint as:

• Many implementations of signals are "unfixable". Not just the one in the implementation of Perl in Windows.
• Signals are no proper IPC mechanisms.

Could you accept (or even recommend) the addition of something like this:

It is strongly advice against using signals for Inter Process Communication. This is particular important in Perl code intended to be portable.

to the Perl documentation? The addition could be done to the function kill in the Perl Language reference.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.