Re: Path to PostgreSQL portabiliy - Mailing list pgsql-hackers

From Nicolas Bazin
Subject Re: Path to PostgreSQL portabiliy
Date
Msg-id 001b01c1f6ee$4358b1a0$660d090a@software.ingenico.com.au
Whole thread Raw
In response to Path to PostgreSQL portabiliy  (mlw <markw@mohawksoft.com>)
List 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 by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Queries using rules show no rows modified?
Next
From: Matthew Kirkwood
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports