From owner-freebsd-threads@FreeBSD.ORG Fri Sep 17 00:01:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55E6D16A4CF; Fri, 17 Sep 2004 00:01:13 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38DAC43D48; Fri, 17 Sep 2004 00:01:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id F3EC37A3D2; Thu, 16 Sep 2004 17:01:12 -0700 (PDT) Message-ID: <414A2948.9000900@elischer.org> Date: Thu, 16 Sep 2004 17:01:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 00:01:13 -0000 Daniel Eischen wrote: >On Fri, 17 Sep 2004, David Xu wrote: > > >>Daniel Eischen wrote: >> >> >>>We do that in fork(). Is execv() not being done after a fork()? >>> >>> >>> >>> >>Joost calls execv() directly in threaded process, he did not go through >>fork() ->execv() path. >> > >Yes, Julian just emailed me similarly. In that case, I think we need >to wrap execve() and set the kernel signal mask to the threads signal >mask. We don't need all the single threading stuff that is in our >wrapped fork(); just __sys_sigprocmask() should be sufficient. Right? > We would need to ensure that there is no chance that we could be switched to another kernel thread between the two calls. In general I'd prefer it if we had a way that worked even if the userland screwed up.. execve is often a way in which daemons recover when they feel that they have messed up in some way... e.g.: panic() { log("help I've fallen over and I can't get up"); execve( me, argc, argv, envpp); /* or whatever the args are ..ok so I need to write more userland stuff */_ } do we trust userland that much? does the signal therad just enable ALL signals? does it not maks those for which we have no consumers? I'd still prefer to do things that work for libthr as well as libpthread. _