Linux/vxworks signals

Question

I came across the following in a vxworks manual and was wondering why this is the case.

What types of things do signals do that make them undesirable?

In applications, signals are most appropriate for error and exception handling, and not for a general-purpose inter-task communication.

Answer 1

The main issue with signals is that signal handlers are registered on a per process/memory space basis (in vxWorks, the kernel represents one memory space, and each RTP is a different memory space).

This means that regardless of the thread/task context, the same signal handler will get executed (for a given process). This can cause some problems with side-effects if your signal handler is not well behaved.

For example, if your signal uses a mutex for protect a shared resource, this could cause nasty problems, or at least, unexpected behavior

  Task A                       Task B               Signal Handler
  Take  Mutex
   ...
   Gets preempted 
                                does something
                                 ....
                                <SIGNAL ARRIVES>----->Take Mutex  (blocks)
   resumes
   ....
   Give Mutex
                                                ----->Resumes Handler

I'm not sure the example above really conveys what I'm trying to. Here are some other characteristics of signals:

• Handler not executed until the task/process is scheduled. Just because you sent the signal, doesn't mean the handler will execute right away
• No guarantee on which Task/Thread will execute the handler. Any thread/task in the process could run it (whichever thread/task executes first). VxWorks has ways around this.

Note that the above only applies to asynchronous signals sent via a kill call.

An exception will generate a synchronous signal which WILL get executed right away in the current context.