Re: How much work is a native Windows application?

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How much work is a native Windows application?
Date: 2002-05-07 17:52:26
Message-ID: 20020507144710.D32524-100000@mail1.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


http://www.mkssoftware.com/docs/man3/fork.3.asp

http://www.computing.net/programming/wwwboard/forum/60.html

http://www.research.att.com/sw/tools/uwin (Semaphores & Fork)

On Tue, 7 May 2002, mlw wrote:

> I mentioned in another thread, Windows does not support "fork()." PostgreSQL
> seems irrevocably tied to using fork(). Without a drastic rewrite of how
> postmaster works, I don't see a way to make a pure Windows version.
>
> The big trick to cygwin is its implementation of fork(). It represents a very
> important and fairly mature technique. It can be written for PostgreSQL but it
> would require a fair amount of development time and testing.
>
> Then we would need to be able to trace all the native API calls made so that
> things like file handles are dealt with correctly for the child process.
>
> I see cygwin as a portability layer or subsystem, as such, it should be able to
> emulate foreign operating system constructs. A native application should, on
> the other hand, not attempt to do so.
>
> There is a strategy PostgreSQL could use:
>
> Put all global variables which need to be duplicated in a single place, perhaps
> a struct, which can be copied into the child process. On systems without
> fork(), the memory can be duplicated or passed around using a shared memory
> block, on a system with fork(), nothing extra would need to be done. This could
> be implemented using "standard" APIs, with little or no specialized OS
> knowledge.
>
> This represents a lot of reworking of code, but should not affect much in the
> way of operation, but would require a lot of typing and testing. It would also
> force restrictions on module static and global variables.
>
> I will sign up to do the Windows stuff to get this to work, but it will take a
> lot of postgres internal reworking that I am not up for doing.
>
> The other alternative, is to profile PostgreSQL running in the cygwin
> environment and try to assess where any bottlenecks are, and if there are any
> spot optimizations which can be applied.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2002-05-07 18:02:46 Re: OK, lets talk portability.
Previous Message Tom Lane 2002-05-07 17:49:20 Re: How much work is a native Windows application?