From owner-svn-src-head@freebsd.org Sat Jul 11 20:37:06 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEBA59970AA for ; Sat, 11 Jul 2015 20:37:06 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 868C41EF1 for ; Sat, 11 Jul 2015 20:37:06 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by oibn4 with SMTP id n4so1184523oib.3 for ; Sat, 11 Jul 2015 13:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2G63BWi9TdtjOS5qmTX1WJHh/USWKZfcM7cLDBWOfZs=; b=QeXmbj2Yuer7tiCqkc87mfrC+uKoZkzGSJZYqh+zD5/8mhUW19m3i6encbovNsaX2J rvqxF6Uz4qLVnszRLVlQb159UQkSUmExuq0p9dQANv9k368mgfYzgafFYGt8VNxAepXj 5UsSCgV+1ndsdjeyK0nJcltOz8abPpwsSt1gPRytnFVYDl0/QzrkNvImbj9v4bgNj02y DMoJ7YlAQnTmZ71aSo5x3V9YII5HP8MEe2cjXAmORXUHXXVpVC+dPOVzc0fU2LzlssG+ OIg/7So7zy2ePdzUW0E88SFV6kvRyZahNMSNng08+MOyMT5X/Vw9WAyZG5jaD8Eg1PNg bw0A== X-Gm-Message-State: ALoCoQkj0s+M0xZ8V68fv3knCkPyZKRBk1TXFmNGV5jUahg3PEpBJvnfVI4Tx2QAq4Ef66rOH/SL MIME-Version: 1.0 X-Received: by 10.60.50.232 with SMTP id f8mr23858816oeo.55.1436647019509; Sat, 11 Jul 2015 13:36:59 -0700 (PDT) Received: by 10.76.0.46 with HTTP; Sat, 11 Jul 2015 13:36:59 -0700 (PDT) X-Originating-IP: [84.27.222.46] In-Reply-To: <20150711194732.GB2404@kib.kiev.ua> References: <201507111941.t6BJfV1a072539@repo.freebsd.org> <20150711194732.GB2404@kib.kiev.ua> Date: Sat, 11 Jul 2015 22:36:59 +0200 Message-ID: Subject: Re: svn commit: r285404 - head/sys/compat/cloudabi From: Ed Schouten To: Konstantin Belousov Cc: Ed Schouten , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 20:37:06 -0000 Hi Kostik, 2015-07-11 21:47 GMT+02:00 Konstantin Belousov : > 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 Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717