Linus Torvalds announced his Synchronous Signal Delivery mechanism - originally designed as a possible solution for select() and signal races - which uses a regular file descriptor to deliver pending signals. All the normal operations can be performed on it: you can pass it around, duplicate it, read it, etc.

This mechanism introduces the sigfd system call, which "creates a file descriptor that is associated with the particular thread that created it, and the particular signal mask that the user was interested in."

So, synchronous signal delivery allows a process to get signals on-demand, as opposed to it getting pelted by them. Linus pointed out one useful scenario: "So you can have a process that does a sigfd(), forks, and the child can then listen in on the specified signals of the parent."

From:     Linus Torvalds
To:       linux-kernel
Subject:  Synchronous signal delivery..
Date:     2003-02-13 19:46:10

Ok, 
 I talked about select() and signal races in Australia at IBM (forget who
exactly was involved so I just cc'd the usual suspects), and here's a
prototype example of what I suggested as a potential solution.

[ Warning: this goes on top of the current BK tree with all the signal 
  fixes and the generalized "dequeue_signal()" stuff. 

  Also note that it is a prototype, ie the packet returned to "read()" is 
  obviously not the full info, and there may be other issues with this. ]

It's a generic "synchronous signal delivery" method, and it uses a
perfectly regular file descriptor to deliver an arbitrary set of signals
that are pending.

It adds one new system call:

	fd = sigfd(sigset_t * mask, unsigned long flags);

which creates a file descriptor that is associated with the particular
thread that created it, and the particular signal mask that the user was
interested in. That file descriptor can be passed around all the normal
ways: it can be dup()'ed, given to somebody else with a AF_UNIX socket,
and obviously read() and select()/poll()'ed upon.

So you can have a process that does a sigfd(), forks, and the child can 
then listen in on the specified signals of the parent, for example.

NOTE! For it to be useful, the signals that you want to wait on and read()
using the file descriptor obviously have to be blocked, otherwise they'll 
just be delivered the old-fashioned way.

Here's a trivial example program using the new system call:

	#include <stdio.h>
	#include <signal.h>

	#define __NR_syscall (259)

	int sigfd(sigset_t *mask, unsigned long flags)
	{
		void *vsyscall = (void *) 0xffffe000;
		int ret;
		asm volatile("call *%1"
			:"=a" (ret)
			:"m" (vsyscall),
			 "0" (__NR_syscall),
			 "b" (mask),
			 "c" (flags));
		return ret;
	}

	int main(void)
	{
		sigset_t mask;
		int fd, len;
		char buffer[1024];

		sigfillset(&mask);
		sigprocmask(SIG_BLOCK, &mask, NULL);

		fd = sigfd(&mask, 0);
		printf("sigfd returns %d\n", fd);
	
		len = read(fd, buffer, sizeof(buffer));
		printf("read returns %d (signal %d)\n", len, *(int *)buffer);
		return 0;
	}

Just run it, and send the process signals to see what happens.

The above example program is obviously totally useless, and any real use
would have to expand the implementation with addign the full siginfo to
the packet read (which is trivial apart from deciding on what format to
use - it would be good to not have it be architecture-dependent and in
particular it would be horrible to have different formats for different
compatibility layers).

Any real use would also probably be a select() or poll() loop.

			Linus

[full message, including the appended patch]

From:     Davide Libenzi
Subject:  Re: Synchronous signal delivery..
Date:     2003-02-13 20:22:06

On Thu, 13 Feb 2003, Linus Torvalds wrote:

> It's a generic "synchronous signal delivery" method, and it uses a
> perfectly regular file descriptor to deliver an arbitrary set of signals
> that are pending.
>
> It adds one new system call:
>
> 	fd = sigfd(sigset_t * mask, unsigned long flags);
>
> which creates a file descriptor that is associated with the particular
> thread that created it, and the particular signal mask that the user was
> interested in. That file descriptor can be passed around all the normal
> ways: it can be dup()'ed, given to somebody else with a AF_UNIX socket,
> and obviously read() and select()/poll()'ed upon.

That's really nice, I like file-based interfaces. No plan to have a way to
change the sig-mask ? Close and reopen ?
What do you think about having timers through a file interface ?

> Any real use would also probably be a select() or poll() loop.

And sice it supports ->poll(), epoll.

- Davide


From:     Linus Torvalds
Subject:  Re: Synchronous signal delivery..
Date:     2003-02-13 20:25:26

On Thu, 13 Feb 2003, Davide Libenzi wrote:
> 
> That's really nice, I like file-based interfaces. No plan to have a way to
> change the sig-mask ? Close and reopen ?

You can have multiple fd's open at the same time, which is a lot more 
convenient. 

I will _not_ add a fcntl-like or ioctl interface to this. They are ugly 
_and_ there are security issues (ie if you pass on the fd to somebody 
else, they must not be able to change the signal mask _you_ specified).

> What do you think about having timers through a file interface ?

One of the reasons for the "flags" field (which is not unused) was because 
I thought it might have extensions for things like alarms etc. 

		Linus