Date: Mon, 21 Dec 1998 02:40:53 -0800 From: Mike Smith <mike@smith.net.au> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: current@FreeBSD.ORG Subject: Re: Pb with COMPAT_LINUX_THREADS Message-ID: <199812211040.CAA00481@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 21 Dec 1998 02:34:40 PST." <199812211034.CAA11648@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812211040.CAA00481>