Date: Thu, 2 Jul 1998 00:52:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jb@cimlogic.com.au (John Birrell) Cc: jabley@clear.co.nz, freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads Message-ID: <199807020052.RAA01330@usr07.primenet.com> In-Reply-To: <199807012241.IAA01186@cimlogic.com.au> from "John Birrell" at Jul 2, 98 08:41:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807020052.RAA01330>