From owner-freebsd-hackers Wed Sep 17 12:26:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04025 for hackers-outgoing; Wed, 17 Sep 1997 12:26:58 -0700 (PDT) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04012; Wed, 17 Sep 1997 12:26:37 -0700 (PDT) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA08260; Wed, 17 Sep 1997 12:26:36 -0700 (MST) From: Terry Lambert Message-Id: <199709171926.MAA08260@usr02.primenet.com> Subject: Re: What is wrong with this snipet? To: dyson@FreeBSD.ORG Date: Wed, 17 Sep 1997 19:26:35 +0000 (GMT) Cc: karpen@ocean.campus.luth.se, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199709160858.DAA00240@dyson.iquest.net> from "John S. Dyson" at Sep 16, 97 03:58:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only problem that I can see, is the possibility of a signal > being issued while the child is temporarily using (and avoiding actual > use of) the parent's stack. That problem is evil, but there are a couple > of workarounds for it (specifically, there is another rfork bit that says > that it is a thread creation.) We can hold signals until the child thread > is ready to accept them. I suspect that the thread creation bit will be > used to hold signal delivery in the child, and the child will have to > explicitly enable delivery. This will generally be transparent > to the user (unless the user will be writing their own thread support code.) call_on_alternate_stack( thread_main, void *thread_main_args, thread_stack); Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.