From owner-freebsd-current Thu Nov 12 14:46:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04223 for freebsd-current-outgoing; Thu, 12 Nov 1998 14:46:24 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04218 for ; Thu, 12 Nov 1998 14:46:23 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA25462; Thu, 12 Nov 1998 17:46:01 -0500 (EST) (envelope-from luoqi) Date: Thu, 12 Nov 1998 17:46:01 -0500 (EST) From: Luoqi Chen Message-Id: <199811122246.RAA25462@lor.watermarkgroup.com> To: green@unixhelp.org, lists@tar.com, luoqi@watermarkgroup.com Subject: Re: RFSIGSHARE ready? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > But, my experience was that my test app would hang during the > creation of the first thread *unless* I *both* increased > the stack size to a non-zero value *and* moved it out of the > process stack area. That's why I said it didn't seem to be > a good idea to put zero size (or larger) thread stacks into > the process stack area. > I wrote a test problem myself, and I found that mapping into user stack area interfered with the stack autogrow function. To work around this problem, in i386/i386/trap.c around line 632, ignore the return from grow(), and let the page fault still be handled by vm_fault(). -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message