From owner-freebsd-current Mon Dec 21 02:43:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05756 for freebsd-current-outgoing; Mon, 21 Dec 1998 02:43:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles336.castles.com [208.214.167.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA05747 for ; Mon, 21 Dec 1998 02:43:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id CAA00481; Mon, 21 Dec 1998 02:40:54 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812211040.CAA00481@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel C. Sobral" cc: current@FreeBSD.ORG Subject: Re: Pb with COMPAT_LINUX_THREADS In-reply-to: Your message of "Mon, 21 Dec 1998 02:34:40 PST." <199812211034.CAA11648@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 02:40:53 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At Mon, 21 Dec 1998 01:13:24 -0800, you wrote > > > >> The ifdef'd version is to let people look at it and think about it.. > >> possibly as has been suggested, the malloc'd space might only be used if > >> there is a sharing of signals. Otherwise it might remain in the U area. > > > >That's certainly one way of doing it. You could implement structure > >compression by COW off the parent's copy of the struct instead, that'd > >be even more efficient. > > I have been wondering about this... Multithreading is usually used to improve > performance. Wouldn't this "on-demand" allocation of shared signals impact of > performance? You typically thread for the concurrency win, and wear the startup cost as an overhead that you have to pay back with concurrency. Given that at the moment we're looking at a heavyweight thread implementation, this extra allocation is relatively trivial in the scheme of things. My real feeling at the moment is that we need to lurch forward and uncover the problems that these changes are bound to introduce, rather than sticking a few toes in it and letting the code and developers moulder. Just MHO of course. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message