X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id A97D4D1B570 for ; Thu, 25 Sep 2003 15:53:43 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 19960-04 for ; Thu, 25 Sep 2003 12:53:12 -0300 (ADT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by svr1.postgresql.org (Postfix) with ESMTP id 920FDD1B507 for ; Thu, 25 Sep 2003 12:53:11 -0300 (ADT) Received: from stark.dyndns.tv (gsstark.mtl.istop.com [66.11.160.162]) by smtp.istop.com (Postfix) with ESMTP id EE77E36995; Thu, 25 Sep 2003 11:53:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 1A2YQY-0006Kf-00; Thu, 25 Sep 2003 11:53:10 -0400 To: pgsql-hackers@postgresql.org Subject: Re: [pgsql-www] NuSphere and PostgreSQL for windows References: <200309241711.h8OHBMi20283@candle.pha.pa.us> <1064492591.25702.2084.camel@camel> <1794.1064494772@sss.pgh.pa.us> <3F72F0CF.8050108@persistent.co.in> <2683.1064498510@sss.pgh.pa.us> <3F72F85A.5040600@persistent.co.in> In-Reply-To: <3F72F85A.5040600@persistent.co.in> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 25 Sep 2003 11:53:10 -0400 Message-ID: <87he30j255.fsf@stark.dyndns.tv> Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200309/1237 X-Sequence-Number: 44249 Shridhar Daithankar writes: > The little pthreads programming I did on linux/freeBSD tells me that it > supports majority of features except TLS(linux2.4/linuxthreads) and per thread > signals. LinuxThreads is dead. NPTL is the way and the light. It has ELF TLS which for super-fast thread-local storage, proper per-thread signal semantics, as well as not using USR1,USR2 in ways that mess up signal-handling. It also has kernel support for user-space mutexes (strange as that may sound). > >>I am sure local buffers would be lot cheaper than shared buffers. > > On what do you base that? It sounds like pure fantasy to me. RAM is RAM. Well that's not entirely true. Thread context switches don't involve MMU operations the way process context switches do. So even though RAM is RAM, the RAM in the threaded implementation might be faster to access simply because it's already in the processor cache. The process model has to do a TLB flush and load a whole new page table which takes a lot of time to begin with, and then slows down all memory accesses later. -- greg