How many pulses can be queued before next attempt is rejected? There appears
to be a defined limit for signals (_SC_SIGQUEUE_MAX), but not for pulses.
AFAIK, they are handled by kernel in very similar way and carry same amount
of info, does it mean limit is the same? If not, what is it?
I think it should be documened
Igor Kovalenko <kovalenko@home.com> wrote:
How many pulses can be queued before next attempt is rejected? There appears
to be a defined limit for signals (_SC_SIGQUEUE_MAX), but not for pulses.
AFAIK, they are handled by kernel in very similar way and carry same amount
of info, does it mean limit is the same? If not, what is it?I think it should be documened
- igor
The following paragraph is taken from the MsgSendPulse() section of the docs.
“Pulses are queued for the receiving process in the system using a dynamic pool
of memory objects. If pulses are generated faster than they can be consumed by
the receiver, then over a period of time the system queue for the pulses could
reach a low memory condition. If there’s no memory available for the pulse to
be queued in the system, the kernel fails the pulse request with an error of
EAGAIN. If the priority, code and value don’t change, the kernel performs pulse
compression by storing an 8-bit count with an already queued pulse.”
Barry
Hmm. Thanks but now I’m wondering why similar mechanism (no hard limit) is
not used for signals? Or is it in fact used and man page for sigqueue() was
just blindly copied from POSIX specs?
The reason I’m asking is at one of QNX’2000 workshops it was suggested to
use signals instead of pulses due to better efficiency. But if signals
unlike pulses have limit of max 32 pending per process it might not be
enough in many cases with load spikes…
“Operating System for Tech Supp” <os@qnx.com> wrote in message
news:9gvk62$gtu$1@nntp.qnx.com…
Igor Kovalenko <> kovalenko@home.com> > wrote:
How many pulses can be queued before next attempt is rejected? There
appears
to be a defined limit for signals (_SC_SIGQUEUE_MAX), but not for
pulses.
AFAIK, they are handled by kernel in very similar way and carry same
amount
of info, does it mean limit is the same? If not, what is it?I think it should be documened
- igor
The following paragraph is taken from the MsgSendPulse() section of the
docs.“Pulses are queued for the receiving process in the system using a dynamic
pool
of memory objects. If pulses are generated faster than they can be
consumed by
the receiver, then over a period of time the system queue for the pulses
could
reach a low memory condition. If there’s no memory available for the pulse
to
be queued in the system, the kernel fails the pulse request with an error
of
EAGAIN. If the priority, code and value don’t change, the kernel performs
pulse
compression by storing an 8-bit count with an already queued pulse.”Barry
The reason I’m asking is at one of QNX’2000 workshops it was suggested
to
use signals instead of pulses due to better efficiency. But if signals
unlike pulses have limit of max 32 pending per process it might not be
enough in many cases with load spikes…
Sounds like the efficiency of signals might be in some way related to
the lack of dynamic allocation. Everything is a trade-off. Personally,
it is my opinion that (if you are doing real-time) queuing is to be
minimized at every opportunity (since it simply increases latency).
When I used Neutrino (quite a while ago now) the pulses queued up and
compressed and it was very difficult to notice any memory impact. Actually
I’m not sure if I ever did notice even after letting them queue up for a
long time. I was hoping that some limit would be reached so that the call
would fail with a standard error code. But …SendPulse() never failed… it
just kept queuing them up. So I never did find a way to see if the pulses
were queued, it would be nice to know that sometimes. I tried to get
SendPulse() to fail but I never could. Maybe on an embedded system with
extremely limited memory it would be an issue but I had quite a bit. It
could have changed since I used it last though but doesn’t sound like it.
Jon
“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9gvl7k$s4i$1@inn.qnx.com…
Hmm. Thanks but now I’m wondering why similar mechanism (no hard limit) is
not used for signals? Or is it in fact used and man page for sigqueue()
was
just blindly copied from POSIX specs?The reason I’m asking is at one of QNX’2000 workshops it was suggested to
use signals instead of pulses due to better efficiency. But if signals
unlike pulses have limit of max 32 pending per process it might not be
enough in many cases with load spikes…
- igor
“Operating System for Tech Supp” <> os@qnx.com> > wrote in message
news:9gvk62$gtu$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@home.com> > wrote:
How many pulses can be queued before next attempt is rejected? There
appears
to be a defined limit for signals (_SC_SIGQUEUE_MAX), but not for
pulses.
AFAIK, they are handled by kernel in very similar way and carry same
amount
of info, does it mean limit is the same? If not, what is it?I think it should be documened
- igor
The following paragraph is taken from the MsgSendPulse() section of the
docs.“Pulses are queued for the receiving process in the system using a
dynamic
pool
of memory objects. If pulses are generated faster than they can be
consumed by
the receiver, then over a period of time the system queue for the pulses
could
reach a low memory condition. If there’s no memory available for the
pulse
to
be queued in the system, the kernel fails the pulse request with an
error
of
EAGAIN. If the priority, code and value don’t change, the kernel
performs
pulse
compression by storing an 8-bit count with an already queued pulse.”Barry