Hi,
I think I answered this in my response to Tomasz for the most part.
Again, there are lots of online tutorials that will do a better job than
I. Like
https://www.softprayog.in/programming/posix-real-time-signals-in-linux
On 3/21/2023 3:11 PM, Petro Karashchenko wrote:
I've counted 28 signals specified in
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html and
2 (SIGUSR1 and SIGUSR2) are already reserved for application needs. So 31 -
(28 - 2) == 5. One signal value is "reserved" for SIGWORK, so it makes 4
signal values that can be used by application without any questions.
I came from a more "traditional" RTOS environment and despite that I
started with Nucleus 2 that had implementation for signals (not POSIX of
course), but nobody used it in that environment, so I need some more
education here.
When you are talking about "realtime signals", then what use case do you
mean? Because per my understanding there is no way to do publish /
subscribe with signals and signal number and process ID make a tuple, so
same signal value can have a different meaning for process A and process B.
The things seems to be more complicated in case of groups support.
Real time signals are used all over the code as a general IPC. Whenever
a signal is used as an IPC, versus as its pre-defined function, it is a
real time signal. It is really like any other signal except that its
default action is SIG_IGN (ignore) and they can always be caught.
We use them a lot for:
* Signalling events from interrupt handlers to OS code (or even
application code).
* Many drivers have a notification interface that permits an
application to register to receive an signal whenever some event
occurs in the OS. That is use in a POSIX OS much like callbacks are
used on other environments. There are no callbacks from the OS
under POSIX.
99% of the signals in the OS use these real time signals. There is less
use of the standard signals. SIGABRT or SIGINT can terminate a task if
enabled. SIGCHLD notifies of the death of a child task. SIGALRM means
that a timer has expired. I think a few others are used too.
What is the number of "realtime signals" used in applications that are in
the field?
Real time signals get the heavier use. But there are probably no more
than 3 or 4 per task -- typically for the above kind of uses. There can
really be severe design issues if you need more than a couple.
There is really no way to eliminate the standard signals. They will be
defined no matter what you do. but to define the signal to match Linux
be default. For example:
#ifndef CONFIG_SIG_INT
# define SIGINT 2
#else
# define SIGINT CONFIG_SIG_INT
#endif
You really have no option, SIGINT will be defined no matter what you
do. It will either be a value packed tight at the bottom of the signal
numbers or some other number somewhere else (maybe 29, 30, or 31). I
suppose you could eliminate it by defining to be the same as some other
signal, but that sounds very dangerous to me.
To me replacing the above with just:
#define SIGINT 2
would be a good thing to whether or not you increase the number of
signals. The number of signals is really another closely related
discussion.
One thing to do would be to (1) eliminate these mostly useless per
signal configurations and (2) just ask for the number of real time
signals with a default of 2 and an option of 63, then conditionally make
the sigset_t either 32- or 64-bits.
In the past, the signal numbers would automatically pack like:
#ifndef CONFIG_SIG_INT
# define SIGINT (SIGHUP + 1)
#else
# define SIGINT CONFIG_SIG_INT
#endif
I would like to understand the issue deeper before rushing with the
solution. We can adapt most of the modern MCUs to use uint64_t as
segnal set holder (that of cause is depending on CONFIG_HAVE_LONG_LONG and
some compilers will not have that), but that will leave less powerful
variants with 32 bit signal set as a fallback. Maybe for those systems we
do not need so many realtime signals, so that will be an "easy win".
Another option would be an array of uint32_t's with dimension determined
by the number of signals.
Greg
