As per the docs..

SIGEV_SIGNAL_THREAD

Send a signal to a specific thread, depending on the situation:

     * If used with MsgSend*(), MsgReceive*(), and MsgDeliverEvent(), the thread is the one identified by the rcvid that
 MsgReceive*() returns.
     * For timers, it's the thread that called timer_settime().
     * For InterruptAttach() and InterruptAttachEvent(), it's the thread attaching to the interrupt.
     * For asyncmsg_channel_create(), it's a random thread in the process.
     * For SyncMutexEvent(), it's the thread that called the function.

In the case of timers, SyncMutexEvent(), and interrupts, if the thread dies before the event gets delivered, the kernel 
sends the signal to a random thread in the same process.

The following fields are used:

int sigev_signo
     The signal to raise. This must be in the range from 1 through NSIG - 1.
short sigev_code
     A code to be interpreted by the signal handler. This must be in the range from SI_MINAVAIL through SI_MAXAVAIL.
void *sigev_value.sival_int
     A 32-bit value to be interpreted by the signal handler.

The initialization macro is:

SIGEV_SIGNAL_THREAD_INIT( &event, signal, value, code )

Oleh Derevenko wrote:
> Hello!
> 
> In comments, to TimerCreate() there is the following text.
> 
> If you use signals for event notification, note that signals are always delivered to the process and not directly to 
the thread that created or armed the timer. You can change this by using a sigev_notify of SIGEV_SIGNAL_THREAD.
> 
> Does this mean that in case of SIGEV_SIGNAL_THREAD signal will be delivered to a thread that armed the timer (i.e. 
called timer_settime())?
> If the answer is "yes" that's very bad for me and that limits the usability of feature. I would prefer to be able to 
schedule the timer from any threads while receiving signals in a thread that created the timer.

I think you will have to use SIGEV_SIGNAL and mask the signal from all threads but your timer notification thread then.

> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post26783
> 

-- 
cburgess@qnx.com