From owner-svn-src-all@freebsd.org Sat Jul 11 20:37:06 2015 Return-Path: Delivered-To: svn-src-all@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 B5C6F9970A9 for ; Sat, 11 Jul 2015 20:37:06 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 867611EEE for ; Sat, 11 Jul 2015 20:37:06 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by oihq81 with SMTP id q81so18136560oih.2 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=iKY6/jcmevxQWzp2TyrFOBavERGeIXTxFXMW9/rsFPcDj+J4rJpwgygv51P4JG1Asp NW9k/lPse7i8MXIN6NiNV3tn7PgWhZVeiX81u/XAMQrqHQr+V1Q9429BNjAR61NJUH2L xJYpVLjNO6aLvsSMZ5ODxsT3ojmDBEM7yvB6MOa8dVx4fKEOIRjEK0UEpEVvlVG/eA29 QrFhqC5SI050KVPP8fZekCncrfxxJJmlrSLxgFNs6uHh1n/q93oqy3qXOPygH3LzwOg+ UHrJlNCsQDgIFTVG4FgdpdxNuswWQcfjuZkg40uCU4VKi1I9WXE2oOhR8zhFLNiJ+4qK Pn8Q== X-Gm-Message-State: ALoCoQlZLnH2wOUdjMIGNdZfvJeR+AoygvmnKyAfxD67U8fGVevo9h296V0rYatZU/uHtfr9zVt9 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-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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