HP OpenVMS Systems

Blocking signals in DECthreads?

» close window

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.
 

  

     

     
answer written or last revised on ( 14-MAY-1999 )
     
» close window