Hi Kostik, 2015-07-11 21:47 GMT+02:00 Konstantin Belousov <kostik...@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 <e...@nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
