The purpose of this post is to make me and hopefully also other to understand more about the handling of signal in Windows. Knowledge about signals in Windows is essential, if you want to implement a portable module which uses signals.
I have several times been “hit” by signals in Windows, mainly as a user of modules. I have also tried to understand how signals can be used in Windows. In the Perl documentation I have only found some sentences about it. If you are a UNIX/Linux user and want to write portable code, you get probably very little help from the documentation. Without clear statements of what is wrong it is also difficult to send bug reports.
Super Search gives a lot of information about the topic, but often in specific situation. The results from Super Search show that this is a difficult area. It also show that there is a lot of knowledge in the Monastery.
Some of the background to my proposals and questions are at the end of the post.
What could be done?
Here follows a list of things that could be done to improve portability of modules, in particular from UNIX to Windows. Some of them are perhaps not realistic but can anyway trigger other ideas.
Discourage use of signals
State that: “If you want to write cross-platform code, you shouldn't use signals, full stop.”
Perlwin32 in the Perl documentation says: “Using signals under this port should currently be considered unsupported.” If this still applies, this information should also be placed so module developer using other operating system is aware of it and do not use signals in modules intended to be portable.
Depreciate signals between threads in Windows
Eventually make it impossible from Perl to use signals between threads in Windows.
If you use signal in a wrong way there is a risk to also disturb thing outside the Perl program. Using signal in an inappropriate way can result in a stochastic behaviour of Perl programs.
Discourage use of fork
Make people aware of the big difference between fork in UNIX and Windows. In many cases will the differences result in portability problems.
To support the moved from fork, there should be examples showing how to, in a portable way, solve function typically solved by using fork.
Depreciate fork in Windows
Phase out fork in Windows.
New pragma use portable
Introduce a pragma which issues a warning when non portable functions are used.
Use Perl::Critic to enforce portability
Use the Perl::Critic extensible framework to enforce coding guidelines for portability. It can also be used to indicate “dangerous” functions and constructs.
Questions
Portable alternatives
Is threads a portable alternative to fork?
Is there any portable and feasible ITC alternative to signals in Windows?
Documentation of signals in Windows
In “win32/win32.c” there is a mapping between signals and Windows events. You can also read things like “the child may be blocked in a system call and never receive the signal”.
Where can I find information about this in the documentation of Perl?
Background
TerminateThread is a dangerous function
In the win32 implementation of Perl, ”kill -9 style un-graceful exit” is using ”TerminateThread”.
The “Remarks” in the documention of TerminateThread contains:
TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.
...
TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:
- If the target thread owns a critical section, the critical section will not be released.
- If the target thread is allocating memory from the heap, the heap lock will not be released.
- If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
- If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.
Threads and processes should terminate themselves
Re: Proposal how to make modules using fork more portable
IPC and ITC are different but mixed up
The common fork model is to create a (child) process and the communication between parent and child is Inter Process Communication (IPC).
However in Windows fork creates a (child) thread within the process. The communication between parent and child in Windows is an Inter Thread Communication (ITC). The separation between processes are different than that between threads. Threads are typically sharing more things than processes.
An ITC signal in Windows do not interrupt a blocked I/O operation.
“Signals and Windows: Very limited emulation by Perl. Not reliable.”
“Signals and threads: They are not a useful mechanism of Inter-Thread Communications.”
Stochastic behaviour of Perl program in Windows
Using signal in an inappropriate way can result in a stochastic behaviour of Perl programs. I have seen cases when this not just influence the Perl program, but also other processes in the Windows system. In some cases it is even not possible to switch off the system in the normal way.
I would hesitate to use a program with a stochastic behaviour in a production system.
Another consequences of the "none-deterministic" behaviour is that the module tests should be run several times.
Best Regards
Bo Johansson
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Threads and signals in Windows
by BrowserUk (Patriarch) on Mar 08, 2013 at 10:37 UTC | |
by bojinlund (Monsignor) on Mar 09, 2013 at 08:54 UTC | |
by BrowserUk (Patriarch) on Mar 09, 2013 at 16:37 UTC | |
by bojinlund (Monsignor) on Mar 10, 2013 at 07:01 UTC | |
by BrowserUk (Patriarch) on Mar 10, 2013 at 10:15 UTC | |
Re: Threads and signals in Windows
by zentara (Archbishop) on Mar 08, 2013 at 12:34 UTC | |
by bojinlund (Monsignor) on Mar 11, 2013 at 08:45 UTC | |
by BrowserUk (Patriarch) on Mar 11, 2013 at 18:16 UTC | |
by Anonymous Monk on Mar 11, 2013 at 09:22 UTC | |
by bojinlund (Monsignor) on Mar 11, 2013 at 12:21 UTC | |
by Anonymous Monk on Mar 11, 2013 at 20:09 UTC | |
| |
Re: Threads and signals in Windows
by Anonymous Monk on Mar 09, 2013 at 02:01 UTC | |
Re: Threads and signals in Windows
by sundialsvc4 (Abbot) on Mar 11, 2013 at 16:08 UTC | |
by BrowserUk (Patriarch) on Mar 11, 2013 at 17:58 UTC | |
by Anonymous Monk on Mar 11, 2013 at 20:00 UTC | |
by sundialsvc4 (Abbot) on Mar 11, 2013 at 21:54 UTC | |
by BrowserUk (Patriarch) on Mar 11, 2013 at 23:10 UTC | |
by Anonymous Monk on Mar 11, 2013 at 22:48 UTC | |
|