From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>, "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: New win32 signals patch (3) |
Date: | 2004-02-04 16:28:01 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE34B12C@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
> > The limit for select on win32 is actually 64, which is
> horribly low in
> > many cases.
>
> Wow, that small and they don't have poll()? Whatta bunch of bozos.
Well, they have other methods. Such as their "I/O Completion Ports",
which I've seen easily handle 30-40,000 sockets (IIRC that's the number
- it was at least very large)... But they do like to do things their own
way...
> > But as it is right now, select() is only used in the
> postmaster and in
> > the pgstat process, neither of which use any large number of fds.
> > Since we only select() on sockets, and not the files.
>
> Okay. I thought I had seen something about using select() in
> the context of catching signals, in which case it'd be
> necessary to use it in all backends. But if not then we can
> probably live with the small fd_set size.
If you're talking win32 port specific, I think it was the other way
around. Using select() *prevents* catching signals with the current
implementation. This is why we need the "select replacement", see my
latest patch.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-02-04 18:41:03 | Re: Sync vs. fsync during checkpoint |
Previous Message | Tom Lane | 2004-02-04 16:18:20 | Re: New win32 signals patch (3) |