From owner-freebsd-stable Mon Dec 11 13:51:50 2000 From owner-freebsd-stable@FreeBSD.ORG Mon Dec 11 13:51:44 2000 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from shell.webmaster.com (unknown [216.152.64.152]) by hub.freebsd.org (Postfix) with ESMTP id 96B9837B402 for ; Mon, 11 Dec 2000 13:51:44 -0800 (PST) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Mon, 11 Dec 2000 13:50:31 -0800 From: "David Schwartz" To: "Vivek Khera" , Subject: RE: MySQLd not using both CPUs Date: Mon, 11 Dec 2000 13:51:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <14900.63315.37162.936895@onceler.kciLink.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My question is do you still need to link libc_r to get thread-safe > versions of all the other functions or are they all thread-safe in > standard libc already? The pthread man page says this: You *can't* use libc_r with the LinuxThreads port. It provides a different type of threading than the LinuxThreads port does. However, LinuxThreads does build a gcc_r library to provide reentrant versions of critical internal functions and the llthreads library contains reentrant versions of crtical library functions. > The current FreeBSD POSIX thread implementation is built in > the library > libc_r which contains both thread-safe libc functions and the thread > functions. This library replaces libc for threaded applications. > > This implies to me that standard libc is not thread safe, which could > be a problem in this case. The LinuxThreads port makes sure that vital functions (like malloc) are thread-safe. I have yet encountered only two cases where either the function wasn't replaced or there wasn't a corresponding thread-safe function. Those were 'ctime' and 'asctime' (the port attempts to replace them with thread-safe versions, but I couldn't get the replacements to work properly). Fortunately, no multithreaded program I've had to deal with has used either of them, and if they did, I could work around it by wrapping the functions in a mutex until the results were copied to thread-local storage. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message