Re: Path to PostgreSQL portabiliy
От | Nicolas Bazin |
---|---|
Тема | Re: Path to PostgreSQL portabiliy |
Дата | |
Msg-id | 001b01c1f6ee$4358b1a0$660d090a@software.ingenico.com.au обсуждение исходный текст |
Ответ на | Path to PostgreSQL portabiliy (mlw <markw@mohawksoft.com>) |
Список | pgsql-hackers |
I think that cygwin is just a hack that allows you to distribute a software developped for UNIX under Windows. I see the point for using it in a company that wants to have a bigger market and doesn't really care about the speed of its application (because cygwin slows down your application quite a bit). But an open source project should try to have the best implementation, most of all the main site. If you want a port to Windows with cygnus, let other sattelite projects do it as they already exist, and add links to these projects to the home page. May be its time again to dig up this old subject of thread support. Even the Unix implementation could have a mixed multi-process multi-thread architecture. The postmaster could start a certain number of processes each process beeing able to be multi-threaded if the platform supports it. If you really don't want of threads it is possible to implement a event demultiplexer loop and each process can benefit of any delay to do something else. Then you benefit of idle time in the connexion and even after further optimization you can benefit of idle time during I/O. One good start point is the GNU Pth library that implements cooperative threads. It's a good start because it is supported on many platforms and it's easier to implement thread support step by step: cooperative in an event demultiplexing way and then preemptive. Pth has a Posix layer to keep all things more standard. Regards, Nicolas ----- Original Message ----- From: "Paul Ramsey" <pramsey@refractions.net> To: "mlw" <markw@mohawksoft.com> Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Thursday, May 09, 2002 5:53 AM Subject: Re: [HACKERS] Path to PostgreSQL portabiliy > mlw wrote: > > > > No matter what steps you take, cygwin will not be seen by Windows users as > > anything but a sloppy/messy/horrible hack. It is a fact of life. You are > > welcome to disagree, but I assure you it is true. > > Just to clarify here: is it confirmed that having the complete cygwin > distribution is a necessary condition to having a running PostgreSQL on > windows? Is it not possible that, having built postgresql with the full > cygwin, it would be possible to make a nice clean setup.exe package > which bundles the postgresql executables, the required cygwin dlls and > other niceties into an easy install package? Given that, I do not think > your putative windows user would care at all about what was going on > under the covers. As long as the install was clean, there were utilities > (pgadmin?) to start working with the database right away, and things > "just worked", the ugliness (or exquisite symmetry... I am not an > expert) of the fork() implementation really would not be an issue :) > > Of course, an imaginary beautiful packaging regime hinges on the > possibility of bundling the cygwin api libraries cleanly without > bundling all the rest of the cygwin scruft (unix directory heirarchy, > etc etc). Anyone have any light to shed on cygwin's "packagability"? > > P. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
В списке pgsql-hackers по дате отправления: