From owner-freebsd-hackers Thu Jul 2 01:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA01747 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:16:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA01625 for ; Thu, 2 Jul 1998 01:16:00 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id KAA14182; Thu, 2 Jul 1998 10:15:17 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id KAA14039; Thu, 2 Jul 1998 10:15:33 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 02 Jul 1998 10:15:32 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: Joe Abley Subject: RE: pthreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > 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