Date: Sat, 11 Jul 2015 23:56:11 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ed Schouten <ed@nuxi.nl> Cc: Ed Schouten <ed@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285404 - head/sys/compat/cloudabi Message-ID: <20150711205611.GC2404@kib.kiev.ua> In-Reply-To: <CABh_MK=wtpr-zn3N8dV5k7UnVNjv1XZ9ikdmVi8sg-faVr4jQA@mail.gmail.com> References: <201507111941.t6BJfV1a072539@repo.freebsd.org> <20150711194732.GB2404@kib.kiev.ua> <CABh_MK=wtpr-zn3N8dV5k7UnVNjv1XZ9ikdmVi8sg-faVr4jQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 11, 2015 at 10:36:59PM +0200, Ed Schouten wrote: > Hi Kostik, > > 2015-07-11 21:47 GMT+02:00 Konstantin Belousov <kostikbel@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). Might be. > Bucket 2: The system call could also just fail and return an error > (MSG_NOSIGPIPE). SIGPIPE exists to ensure that naive programs do something reasonable when their stdout suddenly goes away. Or, transposing the PoV, it allows to write useful and well-behaving programs while ignoring complications. If all programs must be aware of the special error code from write which indicates that nobody listens to the output anymore, it would cause unneeded code copy/pasted all over the src. > > 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. The third bucket, AKA synchronous signals AKA traps, have the correct interface for passing the traps on kernel<->user boundary. Your complain could be read as desire to have e.g. SEH available. This is ortogonal to the signal interface, which is adequate to implement any desired superstructure on top of it. > > 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 what I read as a proposal for top-hamper on top of the raw signal delivery mechanism. I think that high-level languages must do that, and I am happy that C gives me direct access to the trap interceptions for some things that I do. > > 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. No. The point of my first message is that kern_sigaction + list is the unmaintanable approach. Take a look at the execsigs() again. You should implement a loop over the ps_sigignore sigset similar to the loop over ps_sigcatch in execsigs. Then you do not need to maintain a signal list. Later, when you design an interface to reflect traps to the userspace in your ABI, you would have some table to translate trap identifiers (or whatever) to FreeBSD signals. Right now you do not need them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150711205611.GC2404>