From owner-freebsd-hackers Wed Jul 1 17:53:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA28173 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 17:53:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA28155 for ; Wed, 1 Jul 1998 17:53:15 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA17822; Wed, 1 Jul 1998 17:53:15 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd017736; Wed Jul 1 17:53:05 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA01330; Wed, 1 Jul 1998 17:52:59 -0700 (MST) From: Terry Lambert Message-Id: <199807020052.RAA01330@usr07.primenet.com> Subject: Re: pthreads To: jb@cimlogic.com.au (John Birrell) Date: Thu, 2 Jul 1998 00:52:59 +0000 (GMT) Cc: jabley@clear.co.nz, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807012241.IAA01186@cimlogic.com.au> from "John Birrell" at Jul 2, 98 08:41:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Why was the decision made to support pthreads in this manner? > > I wasn't allowed to destablize libc. > > > What > > benefits does this have over the Solaris way of doing things? > > I doubt there are any. As far as libc being thread safe at all times, I think this would be a mistake, until such time as kernel and user space cooperative scheduling was actually working. This is because a user space threaded process competes for quantum as one process against all of the other multiple process service implemetnations on your machine. It would be very easy to be out-competed for quantum without this; they you have to play priority and scheduler games just to get back up to par with the unthreaded processes. 8-(. As far as the kernel threading requirement: it's because the user space code in libc wrapping the system calls. This code adds not inconsiderable overhead, and it would be an oppressive burden to foist off on non-threaded processes not gaining benefit from the burden they would have to assume. In any case, there's *currently* a benefit in that the wrappering overhead doesn't have to be eaten by non-threads-using programs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message