On Thu, 9 May 2002, Jan Wieck wrote: > > If postgresql IS going to eventually be multi-threaded, then the whole > > win32 port should probably be delayed until then, since it would solve > > many of the issues of fork() versus createprocess(). > > If multi-threading is the plan, then there is light at the > end of the tunnel ... the upcoming train...
That's a bit extreme don't you think? I'm not fan of multi-threading as the one true way, and since I use linux as my server for postgresql, there is no gain for me in a multi-threaded model. In fact, I'd prefer postgresql stay multi-process for robustness. BUT, if there are plans to go multi-thread, or could be plans, then those should take priority over how to port to windows, since making postgresql multi-threaded will change it so much as to make the current "how do we port to windows" thread meaningless. One of the primary reasons given for avoiding cygwin is that postgresql runs so slowly under it on windows, but I submit that it probably won't run a heck of a lot faster if it was written as a native app as long as it's running as a multi-process design. Since there's probably no great gain to be had from moving it out from under cygwin, why bother? My vote would be to stay multi-process and Unix compatible. I have no real use for windows as a server, and do NOT want to sacrifice the performance / reliability I have with postgresql under Linux for a windows port. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
