| From: | Jason Tishler <jason(at)tishler(dot)net> |
|---|---|
| To: | mlw <markw(at)mohawksoft(dot)com> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: HEADS UP: Win32/OS2/BeOS native ports |
| Date: | 2002-06-03 13:28:48 |
| Message-ID: | 20020603132848.GB1020@tishler.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
> Bruce Momjian wrote:
> > mlw wrote:
> > > Like I told Marc, I don't care. You spec out what you want and I'll write
> > > it for Windows.
> > >
> > > That being said, a SysV IPC interface for native Windows would be kind of
> > > cool to have.
> >
> > I am wondering why we don't just use the Cygwin shm/sem code in our
> > project, or maybe the Apache stuff; why bother reinventing the wheel.
>
> but! in the course of testing some code, I managed to gain some experience
> with cygwin. I have seen fork() problems with a large number of processes.
Since Cygwin's fork() is implemented with WaitForMultipleObjects(),
it has a limitation of only 63 children per parent. Also, there can
be DLL base address conflicts (causing Cygwin fork() to fail) that are
avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is
currently *not* affected by this issue where as other Cygwin applications
such as Python and Apache are.
Jason
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mlw | 2002-06-03 13:36:51 | Re: HEADS UP: Win32/OS2/BeOS native ports |
| Previous Message | Jason Tishler | 2002-06-03 13:18:40 | Re: HEADS UP: Win32/OS2/BeOS native ports |