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 AC6DCD1B4F2 for ; Thu, 25 Sep 2003 17:09:11 +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 29619-09 for ; Thu, 25 Sep 2003 14:09:01 -0300 (ADT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by svr1.postgresql.org (Postfix) with ESMTP id 71AADD1B4ED for ; Thu, 25 Sep 2003 14:09:00 -0300 (ADT) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A2Zbr-0004Te-00; Thu, 25 Sep 2003 19:08:55 +0200 Received: from [80.129.133.125] (helo=pse-consulting.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A2Zbq-0005rn-00; Thu, 25 Sep 2003 19:08:55 +0200 Message-ID: <3F732126.7040808@pse-consulting.de> Date: Thu, 25 Sep 2003 19:08:54 +0200 From: Andreas Pflug User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Dunstan Cc: Postgresql Hackers 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> <3F72F487.7060603@dunslane.net> In-Reply-To: <3F72F487.7060603@dunslane.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200309/1247 X-Sequence-Number: 44259 Andrew Dunstan wrote: > Tom Lane wrote: > >> BTW, I've been wondering lately if we'd not be better off to look at >> using threading in the Windows port, if it'd help us get around the >> fork/exec data transfer problem. I'm not sure that it would, mind you, >> but if it would give an answer it might be a lot less painful than >> solving the data transfer problem directly. >> > > I am sure you are correct. The whole Windows API is more multi-thread > friendly than multi-process friendly, and operates far more > efficiently that way, as I understand it. There is also some potential > benefit on some *nix systems, where thread creation is far less costly > than forking, or at least this used to be the case last time I looked > at it. > >> >> Our main objections to threading in the past have always been lack of >> portability and loss of robustness. Portability isn't an issue for a >> Windows-only solution, and I'm not too concerned about the other either, >> since I'll never think that Windows would be a place to run a production >> server anyway. >> >> >> > Not that I like Windows all that much, but using it for a server is > becoming more defensible as an option. As for portability, what *nix > is there these days that doesn't have some sort of lightweight thread > support? > > Maybe the relevant parts of the system need to be abstracted out and > threading generally made a build time option (on by default for > Windows, off by default otherwise, maybe?) This seems to be the best option. Whether a specific *ix application really benefits from threads or suffers from this, should be evaluated on each platform. Having this option is certainly advantageous. BTW, this would lower the problems with memory over-commit: no forking, no spare mem allocation needed, right? Regards, Andreas