Re: [pgsql-www] NuSphere and PostgreSQL for windows

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [pgsql-www] NuSphere and PostgreSQL for windows
Date: 2003-09-25 17:08:54
Message-ID: 3F732126.7040808@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message scott.marlowe 2003-09-25 17:15:02 Re: PL contribution guidelines?
Previous Message Tom Lane 2003-09-25 17:07:41 Re: Is this a commit problem?

Browse pgsql-www by date

  From Date Subject
Next Message Josh Berkus 2003-09-25 17:22:28 Re: Shell/FTP access for Techdocs?
Previous Message Devrim GUNDUZ 2003-09-25 17:01:38 About developer.PostgreSQL.org redesign