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.
>
