Re: How much work is a native Windows application?
От | Marc G. Fournier |
---|---|
Тема | Re: How much work is a native Windows application? |
Дата | |
Msg-id | 20020507144710.D32524-100000@mail1.hub.org обсуждение исходный текст |
Ответ на | How much work is a native Windows application? (mlw <markw@mohawksoft.com>) |
Список | 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. >
В списке pgsql-hackers по дате отправления: