add more user-defined signals

Applications Programming
1

Hi

Is there a way to add more user-defined signals?
I am currently using SIGUSR1 and SIGUSR2 - but I need another one.
How can I do that?

Thanks!

2

The signals are defined in the POSIX standard (IEEE Std 1003.1-2001), and implemented in the kernel. Unless you want to break compatibility with all other Unices I'd advise using other methods of IPC, eg messages via shared memory.

3

Unfortunately, there is no way to add signals. If you don't want to use other forms of IPC (you should look into this if you're likely to add more signals - a named pipe that accepts a line telling it what action to take is quite common) you can "hijack" one of the other ones. SIGHUP is quite commonly used to indicate a program should reload all/part of its config, so that's one that won't cause too much surprises (especially if you use it for that express purpose).

4

1) In case I "take over" SIGHUP signal, can I use the "kill" function in order to raise it?
kill(pid, SIGHUP);
and the signal function in order to catch it on the other side?
signal(SIGHUP, sig_handler)

2) Just to make sure I understand the second you were talking about (IPC messages / named pipe) it requires both processes to "pull" from the shared memory the details and don't have something to wake the process (or in other words- it doesn't signal the process) right?
If so, that doesn't help me...

5

Yes - there is no real difference between SIGUSR1/SIGUSR2 and SIGHUP - you can kill() them in exactly the same way, and you set up the signal handler with signal() in the same way.

I'm not sure about what you mean by "pull" from shared memory - there's certainly no requirement to actually use any shared memory. Both processes will need to know the name of the pipe. While it doesn't technically speaking "signal" the process, you can make a blocking read() from the pipe, and you're blocked until someone writes to it/there's an error, so your program will sit dormant until there's something to do.

6

Pick another signal - one that will not be raised by any of the system calls, one that you can block.

This is by no means guaranteed to work. If your system supports realtime signals you can look into those as well. They may be called something like RTMIN or RTMAX.

kill -l ( that is the letter L lowercase) lists all of the signals on your system.

7

If your system has realtime signals, you can use them. SIGRTMIN, SIGRTMIN+1, ..., SIGRTMAX are signals with no predefined meaning. Note that the first two are already used in older Linux systems for thread management, so avoid them.

8

Hi Corona688
Sorry for the late reply, but it took me a while to test your recommendation about real-time signals.

My system also have a CLI and it seems that using real time signals interrupt the CLI. Is it the common behaviour of CLI with RT signals or is it something I need to check in our impelemntation of the CLI ?

Thank you!

#7
5 Days Ago
Corona688

---------- Post updated at 01:11 PM ---------- Previous update was at 01:10 PM ----------

Hi Corona688

Sorry for the late reply, but it took me a while to test your recommendation about real-time signals.

My system also have a CLI and it seems that using real time signals interrupt the CLI. Is it the common behaviour of CLI with RT signals or is it something I need to check in our impelemntation of the CLI ?

Thank you!

9

Please don't PM me in the hope of provoking a faster reply. I get PMs when I log in.

I cannot tell why it's freezing without seeing your code.

10

Thank you
I solved it