From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> |
Cc: | "'Magnus Hagander'" <mha(at)sollentuna(dot)net>, pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: New win32 signals patch (3) |
Date: | 2004-02-04 15:36:13 |
Message-ID: | 12932.1075908973@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
>> Actually, I noticed we *already* do memcpy on fd_sets in the
>> postmaster, so it's nothing new. I don't think it'll be a problem.
> Under Win32, which specifically states of fd_sets "data representation is
> opaque", I'd argue that it isn't strictly a good idea... but clearly, by
> inspection of the Win32 fd_set type, it'll work (and would clearly continue
> to do so for any sensible implementation of fd_sets), so I have a pretty low
> care-factor... :-)
I missed the reason for agonizing over fd_sets, but maybe you should be
thinking about using poll() instead of select() anyway?
select() is a bit risky since it can fail if the process has enough FDs
open to exceed whatever the FD set size is --- you may be wishing to
wait on an FD that can't be represented in an fd_set. This cannot
happen in the postmaster, which never has more than a few files open,
but for general-purpose use in backends I'd much rather see us use
poll() on all platforms that have it. I assume Windows does...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2004-02-04 15:46:08 | Re: New win32 signals patch (3) |
Previous Message | Merlin Moncure | 2004-02-04 14:35:00 | Re: interix port running... |