|Do you know where your variables are?|
Threads and signals in Windowsby bojinlund (Vicar)
|on Mar 08, 2013 at 09:39 UTC||Need Help??|
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.
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?
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:
Threads and processes should terminate themselves
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.