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
That is not right. I am mis-remembering. Getting old sucks.
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,
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 s
Thank You Greg! :-) :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
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 app
== Question Part ==
Can those customs signals be implemented with ioctl/sysctl api or
other standard mechanism that would provide system compliance with
other OS?
How would that change impact future software porting to NuttX when its
big enough to run "big" applications known from our desktop
On Tue, Mar 21, 2023 at 9:11 PM Gregory Nutt wrote:
>
> Linux supports 64 signals. Originally it supported 32 signals but:
>
> The addition of real-time signals required the widening of the signal set
> structure (/sigset_t/) from 32 to 64 bits. Consequently, various system
> calls were sup
Linux supports 64 signals. Originally it supported 32 signals but:
The addition of real-time signals required the widening of the signal set
structure (/sigset_t/) from 32 to 64 bits. Consequently, various system calls
were superseded by new system calls that supported the larger signal se
I think I am mixing three related things here:
1. OPEN_MAX which controls the number of open files. That is 256
2. FD_SETSIZE which is the size of the fd_set. That is the set passed
to select()
3. Number of signals MAX_SIGNO which is really almost unrelated. It is
only related through openin
I think I missed the change that expanded signal values to 255 and I think
that GOOD_SIGNO() macro still checks for <= 31.
These 463a4377331, 24bd80eb84d, fa3e0faffcb, 10852dcc25c
Yes, MAX_SIGNO and GOOD_SIGNO are wrong. I also created an Issue for
this: https://github.com/apache/nuttx/iss
On Tue, Mar 21, 2023 at 7:53 PM Petro Karashchenko wrote:
>
> Hello Gregory,
>
> Thank you for your reply.
>
> I think I missed the change that expanded signal values to 255 and I think
> that GOOD_SIGNO() macro still checks for <= 31.
> I will re-examine the code and find it out. I would be glad t
Hello Gregory,
Thank you for your reply.
I think I missed the change that expanded signal values to 255 and I think
that GOOD_SIGNO() macro still checks for <= 31.
I will re-examine the code and find it out. I would be glad to clean-up the
signal values reconfiguration code however recently I saw
Hi, Petro,
The first thing that I would want to know is: Is it really necessary to
be able to reconfigure signal numbers? Is there any real reason to do
that now? I put the configurable signal numbers in because there was a
limit of 31 signals. But recently, that has been extended to 255
13 matches
Mail list logo
