Re: New win32 signals patch (3)

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

In response to

Browse pgsql-hackers-win32 by date

  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...