It is my understanding that QNX v6 has 64 signals. I need about 6
consecutive signals that are otherwise unused. I was naively assuming
that anything above 32 is essentially unsed by the OS. Is this true?
I want to use the sigwait() function in 6 different threads to wait for
a signal that is intended just for that thread. However these functins
seem to be based on a signal mask that only allows up to 32 different
signals.
How would a thread wait for an arbitrary signal above 32?
Bill Caroselli <qtps@earthlink.net> wrote:
It is my understanding that QNX v6 has 64 signals. I need about 6
consecutive signals that are otherwise unused. I was naively assuming
that anything above 32 is essentially unsed by the OS. Is this true?
No.
But, the range you want to use is SIGRTMIN to SIGRTMAX – this is a
range of 16 otherwise unassigned signals for this sort of useage.
I want to use the sigwait() function in 6 different threads to wait for
a signal that is intended just for that thread. However these functins
seem to be based on a signal mask that only allows up to 32 different
signals.
Um…what makes you think that the mask is only 32 bit wide? It
does take a sigset_t, and that is a bit wider than 32 bits.
How would a thread wait for an arbitrary signal above 32?
sigwait() should work, but I would recommend sigwaitinfo() over sigwait().
And, you want to play with sigaddset(), sigdelset(), sigemptyset(),
and sigfillset() for modifying the sigset_t.
David Gibbs
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote:
I want to use the sigwait() function in 6 different threads to wait for
a signal that is intended just for that thread. However these functins
seem to be based on a signal mask that only allows up to 32 different
signals.
DG > Um…what makes you think that the mask is only 32 bit wide? It
DG > does take a sigset_t, and that is a bit wider than 32 bits.
Well, sigsetmask( int mask ) is documentated as taking an int as an
argument. An int is only 32 bits.
Also, sigmask is documented as (1L<<((s)-1)) adn 1L is only 32 bits.
Is the documentation wrong for these types of functions?
How would a thread wait for an arbitrary signal above 32?
DG > sigwait() should work, but I would recommend sigwaitinfo() over sigwait().
Thank you. I will try these.
How would a thread wait for an arbitrary signal above 32?
DG > sigwait() should work, but I would recommend sigwaitinfo() over sigwait().
DG > And, you want to play with sigaddset(), sigdelset(), sigemptyset(),
DG > and sigfillset() for modifying the sigset_t.
The documentation for sigwait says: "The signals defined by set must
be blocked before you call sigwait(); otherwise, the behavior is
undefined. The effect of sigwait() on the signal actions for the
signals in set is unspecified. "
But when I include the lines:
// set up the signal mask
sigset_t set;
sigemptyset( &set );
sigaddset( &set, lsig );
sigblock( set ); // <<<---- line 67
I get:
logger.cc:67: struct sigset_t' used where a int’ was expected
So, how do I block this signal?
You’re mixing API’s here Bill. Checkout sigaction and the
SignalAction() in the docs.
Bill Caroselli wrote:
How would a thread wait for an arbitrary signal above 32?
DG > sigwait() should work, but I would recommend sigwaitinfo() over sigwait().DG > And, you want to play with sigaddset(), sigdelset(), sigemptyset(),
DG > and sigfillset() for modifying the sigset_t.The documentation for sigwait says: "The signals defined by set must
be blocked before you call sigwait(); otherwise, the behavior is
undefined. The effect of sigwait() on the signal actions for the
signals in set is unspecified. "But when I include the lines:
// set up the signal mask
sigset_t set;
sigemptyset( &set );
sigaddset( &set, lsig );
sigblock( set ); // <<<---- line 67
I get:
logger.cc:67:struct sigset_t' used where aint’ was expectedSo, how do I block this signal?
Colin Burgess <cburgess@qnx.com> wrote:
CB > You’re mixing API’s here Bill. Checkout sigaction and the
CB > SignalAction() in the docs.
Well there is obviously something important that I’m just missing.
BTW, in QNX4 days, I was quite good at working with signals.
Here is what I need. I have a number of threads, the exact number is
not known yet. For each thread I want to initialize a repeating timer,
that will generte a unique signal for this thread (this is working).
In the main loop for these threads they are supposed to wait for their
respective signal, do a little bit of work, then wait for the next
signal.
I’m using timer_create() with sigevent set to SIGEV_SIGNAL_INIT(), but
how do I guarantee that the timer created by a given thread will
deliver it’s signal to that same thread?
And how do I wait for that signal?
I have confirmed that the signals are being generated at the right
times.
Is there any particular reason for using signals rather than pulses?
If you are trying to get away from pulse queueing, note that the
realtime signals also queue.
But if you are going to use signals, then I think the sequence is
sigclrset
sigaddset
sigprocmask
sigwaitinfo
(sigpending or sigismember?)
Cheers,
Colin
Bill Caroselli wrote:
Colin Burgess <> cburgess@qnx.com> > wrote:
CB > You’re mixing API’s here Bill. Checkout sigaction and the
CB > SignalAction() in the docs.Well there is obviously something important that I’m just missing.
BTW, in QNX4 days, I was quite good at working with signals.
Here is what I need. I have a number of threads, the exact number is
not known yet. For each thread I want to initialize a repeating timer,
that will generte a unique signal for this thread (this is working).In the main loop for these threads they are supposed to wait for their
respective signal, do a little bit of work, then wait for the next
signal.I’m using timer_create() with sigevent set to SIGEV_SIGNAL_INIT(), but
how do I guarantee that the timer created by a given thread will
deliver it’s signal to that same thread?And how do I wait for that signal?
I have confirmed that the signals are being generated at the right
times.
Colin Burgess <cburgess@qnx.com> wrote:
CB > Is there any particular reason for using signals rather than pulses?
CB > If you are trying to get away from pulse queueing, note that the
CB > realtime signals also queue.
CB > But if you are going to use signals, then I think the sequence is
CB > sigclrset
CB > sigaddset
CB > sigprocmask
CB > sigwaitinfo
CB > (sigpending or sigismember?)
CB > Cheers,
CB > Colin
Well, OK, but the illusion is that the signal is being delivered to the
wrong thread.
So, if a specific thread creates a timer that generates a signal,
is that signal guaranteed to be delivered to that thread?
Well, OK, but the illusion is that the signal is being delivered to the
wrong thread.So, if a specific thread creates a timer that generates a signal,
is that signal guaranteed to be delivered to that thread?
If you use SIGEV_SIGNAL_THREAD, then yes. If you use SIGEV_SIGNAL, no.
Colin Burgess <cburgess@qnx.com> wrote:
CB > If you use SIGEV_SIGNAL_THREAD, then yes. If you use SIGEV_SIGNAL, no.
Big Bright Lightbulb ! ! !
Thanks.
Colin Burgess <cburgess@qnx.com> wrote:
Well, OK, but the illusion is that the signal is being delivered to the
wrong thread.So, if a specific thread creates a timer that generates a signal,
is that signal guaranteed to be delivered to that thread?If you use SIGEV_SIGNAL_THREAD, then yes. If you use SIGEV_SIGNAL, no.
Or, you can make sure the appropriate signals are masked in each
thread.
David Gibbs
dagibbs@qnx.com