|
HP OpenVMS Systemsask the wizard |
|
The Question is: In my multi-threaded application, I need to ensure that signals don't execute in the context of threads which may perform sensitive operations. Under Digital Unix, the pthread_sigmask function lets me block signals from certain threads, but OpenVMS 7.1 with DEC C++ and DECthreads doesn't support this function. Experimentation suggests that the program receives all signals on a distinct thread that I didn't create, but I can't find documentation to tell me that I can rely on this behavior. Thank you for your help. The Answer is : On OpenVMS, Unix signals are not a native part of the operating system -- the OpenVMS analog to Unix signals is the "AST" (asynchronous system trap). Unix signals are emulated by the C RTL, using various native OpenVMS mechanisms. The current C RTL signal model does not include the changes introduced by the 1003.1c revision to the POSIX standard, and as such there are no per-thread signal capabilities. Thus, if a thread blocks or unblocks a signal, the signal is blocked or unblocked on behalf of all threads in the process. When a signal becomes pending against the process, it is immediately delivered to a running thread unless the process has the signal blocked. There is no way in the current model to prevent a signal from being delivered to a particular thread while allowing it to be delivered to other threads. While the C RTL might consider enhancing this, if you have a serious desire to see such an enhancement, the OpenVMS Wizard recommends that you submit a specific request and/or contact OpenVMS product management via the Compaq Customer Support Center. With regard to your observation that your program receives all signals in a thread that you didn't create, the OpenVMS Wizard believes that this behavior is easily explained and that it is not an effect that you can rely on. DECthreads creates one or more "null threads" (depending on whether you have the kernel support for threads enabled and on how many processors there are in your machine) which it schedules to run when all user application threads are blocked. (There may also be other internal DECthreads threads around as well, for other purposes.) Depending on which signals you are sending, and how, and depending on what your process state is when they arrive, the OpenVMS Wizard would presume that you are seeing the signals delivered to a null thread. For example, if you wrote a simple test which calls getchar() in main() and doesn't create any threads; and if you link it /THREADS (or, possibly, even if you don't); and if you run it interactively and hit Ctrl/C, then it will be the null thread which is running when the SIGINT arrives. However, if, instead of calling getchar(), you have the main() sit in a compute-bound loop, the signal handler will run in the context of the initial thread instead of the null thread. Thus you cannot necessarily rely on the signal handler running in the context of any particular thread.
|