I’m new to QNX, and wanted to know why you would use pulses or signals
when a timer fires. Thanks.
Mathew Asselin <m2asselin@yahoo.com> wrote:
I’m new to QNX, and wanted to know why you would use pulses or signals
when a timer fires. Thanks.
Pulses are easier to handle on the receiving side, they won’t interrupt
what you’re doing, forcing the checking of return values, and retries
for many functions, and allow an easy common blocking point for both
client requests (messages) and timer notification (pulses).
Signals are POSIX.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
So when would you use signals? Are signals only a set of predefined
values, as opposed to larger messages such as pulses? When you said that
pulses didn’t interrupt what you’re doing, does that mean that signals
will interrupt every thread that is running, and depending on which thread
has that signal masked, it will be “notified”? Thanks again, this is
helping me out.
Matt.
David Gibbs wrote:
Mathew Asselin <> m2asselin@yahoo.com> > wrote:
I’m new to QNX, and wanted to know why you would use pulses or signals
when a timer fires. Thanks.Pulses are easier to handle on the receiving side, they won’t interrupt
what you’re doing, forcing the checking of return values, and retries
for many functions, and allow an easy common blocking point for both
client requests (messages) and timer notification (pulses).Signals are POSIX.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Mathew Asselin <m2asselin@yahoo.com> wrote:
So when would you use signals? Are signals only a set of predefined
values, as opposed to larger messages such as pulses? When you said that
pulses didn’t interrupt what you’re doing, does that mean that signals
will interrupt every thread that is running, and depending on which thread
has that signal masked, it will be “notified”? Thanks again, this is
helping me out.
Neither pulses nor signals carry much data – they both essentially can
carry a 32-bit integer in addition to a signal number/pulse code. (That
is, pulses are not “larger messages”. They are just received in a manner
similar to larger messages from MsgSend*().)
If a signal is sent to a multi-threaded process, one thread that does not
have the signal masked will be chosen to get the signal, it is the one
that will be interrupted from what it was doing. Others won’t be affected.
The interruption to call the signal handler is the notification.
For a single threaded process, that thread is, of course, the one that
will be interrupted to handle the signal.
-David
–
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Mathew Asselin <m2asselin@yahoo.com> wrote:
So when would you use signals?
Right, I missed answering that bit.
I would use signals if:
POSIX compliance was a must.
I was porting existing code that already used signals.
I wanted to terminate a process.
I would handle signals if I was dealing with the Unix operating
environment which generates signals for certain events, such as
child death (SIGCHLD) or loss of connection (SIGHUP).
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Mathew Asselin <> m2asselin@yahoo.com> > wrote:
So when would you use signals? Are signals only a set of predefined
values, as opposed to larger messages such as pulses? When you said that
pulses didn’t interrupt what you’re doing, does that mean that signals
will interrupt every thread that is running, and depending on which thread
has that signal masked, it will be “notified”? Thanks again, this is
helping me out.Neither pulses nor signals carry much data – they both essentially can
carry a 32-bit integer in addition to a signal number/pulse code. (That
is, pulses are not “larger messages”. They are just received in a manner
similar to larger messages from MsgSend*().)If a signal is sent to a multi-threaded process, one thread that does not
have the signal masked will be chosen to get the signal, it is the one
that will be interrupted from what it was doing. Others won’t be affected.The interruption to call the signal handler is the notification.
For a single threaded process, that thread is, of course, the one that
will be interrupted to handle the signal.-David
–
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Thanks David, this really helps me out. Another quick question relates to
masking the signals. Lets say I have many threads, and I want to mask
certain threads from certain signals. Can I do this from their process,
or do I have to call the funtion signal(signal, signal handler) within
each thread? Thanks again. matt.
Mathew Asselin <m2asselin@yahoo.com> wrote:
David Gibbs wrote:
Thanks David, this really helps me out.
Quite welcome.
Another quick question relates to
masking the signals. Lets say I have many threads, and I want to mask
certain threads from certain signals. Can I do this from their process,
or do I have to call the funtion signal(signal, signal handler) within
each thread?
Neither.
signal() associates (or removes) a handler with, or ignores, a
particular signal. It does not affect the masking of signals.
And, it doesn’t matter which thread does it – it is a process
global decision.
pthread_sigmask() is used to change the signal mask for the
calling thread, and each thread has its own independent signal
mask.
But, the signal mask is inheritted accross thread creation – so
if you set it once in the main thread (the first thread created
at process creation that runs the main() function), it will be
inheritted by all threads created. (Barring situation such as
main thread creates thread 3, which changes mask, and creates
thread 4 – in this case 4 inherits from 3, of course.)
Also, the API and structure of the docs/code is to think of the
behaviour as “masking signals for (from) a thread” rather than
“masking threads from a signal”. Or, to put it another way, you
get to decide “for this thread, which signals it can receive”,
rather than “for this signal, which threads can get it”. Of
course, with care, and from a design level decision, one could
be turned into the other – but it can’t be (easily) done in
any sort of dynamic way.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Mathew Asselin <> m2asselin@yahoo.com> > wrote:
David Gibbs wrote:
Thanks David, this really helps me out.Quite welcome.
Another quick question relates to
masking the signals. Lets say I have many threads, and I want to mask
certain threads from certain signals. Can I do this from their process,
or do I have to call the funtion signal(signal, signal handler) within
each thread?Neither.
signal() associates (or removes) a handler with, or ignores, a
particular signal. It does not affect the masking of signals.
And, it doesn’t matter which thread does it – it is a process
global decision.pthread_sigmask() is used to change the signal mask for the
calling thread, and each thread has its own independent signal
mask.But, the signal mask is inheritted accross thread creation – so
if you set it once in the main thread (the first thread created
at process creation that runs the main() function), it will be
inheritted by all threads created. (Barring situation such as
main thread creates thread 3, which changes mask, and creates
thread 4 – in this case 4 inherits from 3, of course.)Also, the API and structure of the docs/code is to think of the
behaviour as “masking signals for (from) a thread” rather than
“masking threads from a signal”. Or, to put it another way, you
get to decide “for this thread, which signals it can receive”,
rather than “for this signal, which threads can get it”. Of
course, with care, and from a design level decision, one could
be turned into the other – but it can’t be (easily) done in
any sort of dynamic way.-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Ok, I think I follow thus far. But I was just reading from the qnx
website that you can send signals to specific threads. Is this a new
functionality of QNX 6? Or did I not read it correctly. Thanks. Matt.
Mathew Asselin <m2asselin@yahoo.com> wrote:
MA > Ok, I think I follow thus far. But I was just reading from the qnx
MA > website that you can send signals to specific threads. Is this a new
MA > functionality of QNX 6? Or did I not read it correctly. Thanks. Matt.
Hi Mathew,
In QNX4 days I thought I understood signals pretty well. But QNX4 was
essentially a single threaded only environment. I’ve been learning a few
new things about signals in QNX6. Mostly out of necessity. And we all
know that necessity is a mother.
I believe the distinction is that some of the signal functions are older
ANSI functions. Some of the newer signal functions are POSIX and multi-
thread compatable. I have been balled out more than once by QSSL person
for trying to mix the two different “interfaces”. I don’t blame QSSL for
balling me out. I was wrong. I do however wish the documentation had
better explained when it is OK to use one set and when it was OK to use the
other.
Having said all of that, and in an effort to get back to your question of
should I use signals or pulses, I would suggest this.
Signals are a bigger pain in the butt to set up, no doubt. And pulses make
it easier to sychronise exactly when you process the event. BUT . . .
If you have an application where you need to squeeze out every last drop of
performance, go with signals. There is a lot less task swaping between
when the signal is raised and when your signal handler function is called,
than there is between when the Pulse is sent your you finally get around to
MsgReceive() it.
Good luck.
Mathew Asselin <m2asselin@yahoo.com> wrote:
David Gibbs wrote:
Ok, I think I follow thus far. But I was just reading from the qnx
website that you can send signals to specific threads. Is this a new
functionality of QNX 6? Or did I not read it correctly. Thanks. Matt.
Another layer of complexity.
If you are using POSIX functions, then from inside a process, one
thread can send a signal to another specific thread with pthread_kill().
If you are outside the process (e.g. in another process) you can only
target a process for a signal with either kill() or sigqueue().
But, the underlying kernel call, SignalKill(), does take both a
pid and tid.
But, from purposes of system design, it is generally a good idea to
think of processes as objects, and threads as private methods – from
outside the process, you communicate with the process as a whole, and
whether the work is implemented by one thread, two threads, or fifty
threads is not something you need to know, or should know.
If looking at having servers delivers signals through the sigevent
structure, or at requesting signals from a timer, again with a
sigevent structure, there is also a choice – setting the notification
type to SIGEV_SIGNAL or SIGEV_SIGNAL_CODE will deliver the signal to
the process, but setting the notification type to SIGEV_SIGNAL_THREAD
will deliver the notification to the thread that created to the
timer, or which sent the request for notification to the server.
(In both cases, this is the thread/process requesting the notification
that decides whether it will be targeted to the requesting thread,
or the process as a whole – not breaking my above process as an
object model.)
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Mathew Asselin <m2asselin@yahoo.com> wrote:
But I was just reading…
P.S. Reading is dangerous.
Reading increases knowledge, knowledge is power, power is dangerous.
QED.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com