From owner-svn-src-head@freebsd.org Tue Jul 14 10:22:58 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 1203699C0AC for ; Tue, 14 Jul 2015 10:22:58 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (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 D5FE293F for ; Tue, 14 Jul 2015 10:22:57 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by oibn4 with SMTP id n4so3338658oib.3 for ; Tue, 14 Jul 2015 03:22:51 -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=KkrclcJknWwvzmmvWTpO75a1jJMpcYgUooiX7ojoJGc=; b=gnXCnhG8m1TGLPw5oKrSrh4QvDFZ+itzwXFyo8z8GrVTzAiAv5CWFrNNY+++d5HxLQ Xiz2IdaV8SdAoH6G+26pUdlS2me2q/GKdQS7FB8ubhm8cJdlNGzKSzFozPRl/gGZCgNB NO6VXnWgExfJ/RCQi6dVd5ekzHd7lnSEsvErRk5fAQzODmyxM1uy0foeiiZlVqJ1Dmat iMg00Lawe1EoBvPqS9d7/06pCBiHmVR2V9gt05Jeo4USYesRn9Ov25Zdpz/0+j1IFw5A dUk18wvPr7QfPhEQ4UhTKga36iC9yUfE0/q6XI2WGKKNCAnmFov+WwqiTfFcduTiyXxw +U0g== X-Gm-Message-State: ALoCoQm0IA4/eQ6eJ8GSG/cw3wH/3BY787SNdE3ImGcWtro0ZzaJwKSNUuwSAjOoxVNeZe08ghrt MIME-Version: 1.0 X-Received: by 10.202.168.208 with SMTP id r199mr8379609oie.134.1436869371452; Tue, 14 Jul 2015 03:22:51 -0700 (PDT) Received: by 10.76.0.46 with HTTP; Tue, 14 Jul 2015 03:22:51 -0700 (PDT) X-Originating-IP: [84.27.222.46] In-Reply-To: <20150711205611.GC2404@kib.kiev.ua> References: <201507111941.t6BJfV1a072539@repo.freebsd.org> <20150711194732.GB2404@kib.kiev.ua> <20150711205611.GC2404@kib.kiev.ua> Date: Tue, 14 Jul 2015 12:22:51 +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: Tue, 14 Jul 2015 10:22:58 -0000 Hi Kostik, 2015-07-11 22:56 GMT+02:00 Konstantin Belousov : >> 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. Exactly. I think that for programs that are built around pipelines, where a series of processes have stdin/stdout attached, having something like SIGPIPE makes sense. So far the focus >> > 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. Ah, okay. Now I think I understand what you're hinting at. So your proposal is to let cloudabi_sys_proc_raise() only call into sys_kill(), nothing else. We then reset all signals to their default behavior at some point during process startup. Let me address this by the time I'm sending out the CloudABI sysentvec for review, as that would be the place where I'd need to do that. I'll remove the call to kern_sigaction() in the meantime. Does that sound all right? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK/VAT number: 62051717