Date: Thu, 02 Jul 1998 10:15:32 +0200 (CEST) From: Marino Ladavac <lada@pc8811.gud.siemens.at> To: Joe Abley <jabley@clear.co.nz> Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: pthreads Message-ID: <XFMail.980702101532.lada@pc8811.gud.siemens.at> In-Reply-To: <Pine.BSF.3.96.980702080311.2083A-100000@buddha.clear.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-Jul-98 Joe Abley wrote: > Hi all, > > Does anybody know the background of posix thread support in FreeBSD? I > can't seem to find any docs on the background anywhere... > > I'm interested in a couple of issues. > > 1. On Solaris, to compile a pthreaded program, I stick a > > #define _REENTRANT > #include <pthread.h> > > at the top of the source files, and link with -lpthread. With FreeBSD the > linking phase is more involved, since I need to exclude the standard C > libraries and link with libc_r instead. > > Why was the decision made to support pthreads in this manner? What > benefits does this have over the Solaris way of doing things? Because SunOS 5 has kernel thread support and FreeBSD 2.2.6-R does not. This means that on Solaris, when a syscall blocks, a SIGLWP and SIGWAITING can be issued, and the libpthread catches these signals and creates new LWP's (i.e. kernel supported threads) and schedules the user threads on top of them. The morale thereof is that one can use the normal blocking libc syscalls in threaded applications as well without any adverse effects. FreeBSD (and any other pthread implementation without kernel supported threads) must replace all potentially blocking calls with a non-blocking call plus user space thread context switch. All user space pthread implementations known to me use some sort of libc replacement. /Marino 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?XFMail.980702101532.lada>