Date: Mon, 11 Dec 2000 13:51:38 -0800 From: "David Schwartz" <davids@webmaster.com> To: "Vivek Khera" <khera@kciLink.com>, <stable@freebsd.org> Subject: RE: MySQLd not using both CPUs Message-ID: <NCBBLIEPOCNJOAEKBEAKIEIGMGAA.davids@webmaster.com> In-Reply-To: <14900.63315.37162.936895@onceler.kciLink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBLIEPOCNJOAEKBEAKIEIGMGAA.davids>