Re: OK, lets talk portability.
От | Dann Corbit |
---|---|
Тема | Re: OK, lets talk portability. |
Дата | |
Msg-id | D90A5A6C612A39408103E6ECDD77B82906F43D@voyager.corporate.connx.com обсуждение исходный текст |
Ответ на | OK, lets talk portability. (mlw <markw@mohawksoft.com>) |
Список | pgsql-hackers |
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Tuesday, May 07, 2002 7:44 AM > To: Tom Lane > Cc: Marc G. Fournier; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > Tom Lane wrote: > > And no, I don't want to undo those changes. Especially not if the > > only reason for it is to not have to use Cygwin on Windows. Most > > of these changes made the startup code substantially simpler, > > faster, and more reliable. > > Then I think the notion of a pure Windows version is dead in > the water. Writing > a fork()-like API for Windows is, of course, doable as > evidenced by cygwin, and > from a general theory seems like a pretty straight forward > thing to do (with a > few low level tricks of course) but the details are pretty scary. > > Has anyone done a profile of PostgreSQL running on a windows > box and identified > cygwin bottlenecks which we could augment with native code? PW32: http://pw32.sourceforge.net/ has a better fork than Cygwin(), but it is still awful. Much better to start a new server with CreateProcess() on Win32 [absurdly faster]. The idea of fork() translation is to copy the heap and auto data. But the heap can split, so it isn't even really guaranteed to work. Quite frankly, fork() in Win32 is a very, very bad idea. Not just for efficiency reasons but also for reliability reasons.
В списке pgsql-hackers по дате отправления: