svn commit: r285404 - head/sys/compat/cloudabi

[Ed Schouten]

Hi Kostik,

2015-07-11 21:47 GMT+02:00 Konstantin Belousov <kostikbel at gmail.com>:
> This is very strange and unmaintanable approach. Also, you cannot handle
> traps this way.

Yes. That's a pretty good observation.

Some time ago I thought about this and my view is that signals can be
grouped in three buckets:

Bucket 1: Signals that get generated due to some event (e.g. SIGCHLD, SIGWINCH),
Bucket 2: Signals that get generated due to a system call invoked by
the thread itself (e.g. SIGPIPE),
Bucket 3: Signals that get generated due to an instruction executed by
a thread (e.g. SIGSEGV, SIGFPE).

My observation is that if you look at these three buckets, you can
question whether the POSIX signal interfaces are what you'd want:

Bucket 1: These events could also be delivered to the process through
polling (e.g., EVFILT_PROCDESC).
Bucket 2: The system call could also just fail and return an error
(MSG_NOSIGPIPE).

I agree that the third bucket is something that you'd want to support,
of course. Being able to deal with SIGFPE or letting a virtual machine
install a SIGSEGV handler to do all sorts of scary tricks should still
be possible.

That said, I think that the current API we have for that (sigaction,
pthread_sigmask) may not be the best fit. As soon as a single library
within a larger program starts using these interfaces, it may easily
affect the entire process, not just the local space (e.g., the thread)
in which this library operates.

This is why I decided to omit POSIX signal handling for now. There
should appear an interface that could handle the use cases in bucket 3
once the need arises. The API for this may look identical to POSIX --
or not. As long as a good trade-off is made between compatibility,
functionality and modularity.

Be sure to get in touch if you happen to have any opinion on this
matter. I'd love to hear people out.

> If your ABI does not provide any way to install a signal handler, then
> you probably should be already fully set up, due to execsigs() performed
> on each exec(2).

Exactly. The kern_sigaction() is just needed to make sure that if the
process is started up with certain signals ignored, that raise() still
causes the process to terminate. If there is no way you can influence
the signal handling, you'd probably want that functions like abort()
can always throw SIGABRT.

-- 
Ed Schouten <ed at nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK/VAT number: 62051717