I have noticed that in the context of a multithreaded resource manager, when the select() function is called to wait on 
a file descriptor coming from pipe(), the main thread of the resource manager becomes unable to catch the SIGTERM signal
 when the process is slayed.

To reproduce this issue, I have attached a simple resource manager that calls select() on a fd from pipe() whenever a 
read is performed. The select() call normally timeouts after 0.5 ms (results are the same whether I explicitly unblock 
it or not). After that, if the resource manager process is slayed, the following message shows up:

# ./example_g &
# cat /dev/example
# slay example_g

Process 294931 (example_g) terminated SIGTERM code=0 by process 307220 value=0.

If the example is rebuilt with the select() call commented out, SIGTERM is correctly caught by the main thread, and this
 message is seen instead:

Termination Signal correctly received.

This issue is only seen if select() waits on an unnamed pipe. Other file descriptors do not prevent the main thread from
 catching SIGTERM.

Is this a bug in QNX 6.5.0 SP1, or is there something I am doing wrong?

Thanks for your help.