Re: OK, lets talk portability.

> -----Original Message-----
> From: Hannu Krosing [mailto:hannu(at)tm(dot)ee]
> Sent: Tuesday, May 07, 2002 11:29 AM
> To: mlw
> Cc: Tom Lane; Marc G. Fournier; PostgreSQL-development
> Subject: Re: [HACKERS] OK, lets talk portability.
>
>
> On Tue, 2002-05-07 at 19:44, mlw wrote:
> > 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.
>
> There is still another way - use threads.
>
> There you have of course the opposite problem - to determine what to
> _not_ share, but AFAIK this has been done already at least once.
>
> And there seems to be some consensus that doing things that would
> eventually make it easier to use threaded model will probably increase
> code quality in general.

Unfortunately, it opens up another can of worms.

With a fork() [or CreateProcess()] model, the newly spun binary can
inherit a set of rights compatible to the user who attaches. With a
threading model, everyone has the same set of rights. Easier to sleep
at night if you know it is impossible for them to do damage to by
performing an action they should not be able to do. Especially
important if extension functions are added that spawn operating system
tasks.