Re: New win32 signals patch (3)

> > * Nice to see the fix for pqselect. Still want to object to
> > the memcpy "on the record" :-) (though, as we've discussed,
> > they'll work as things are now)
>
> 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... :-)

> > * memcpy of an array of HANDLES will work seems to be taking
> > advantage of knowledge of the implementation. Use DuplicateHandle?
>
> That should be very unnecessary, no? It is knowledge that it is a fixed
> size var and not a pointer, both of which are documented (since pointers
> are all prefixed by P or LP, and HANDLE clearly is not).

As above :-)

> > * Better yet, cooperation with the other functions that use
> > the win32_childHND/PIDArrays, by reserving the first slot for
> > event1, could see us doing away with both event 2 and the
> > need for copying.
>
> No, that won't do away with the need for copying. The backend thread is
> not going to be happy if the main thread goes and changes the array
> underneath it. So you still need a copy. But yes, it could be
> integreated in the win32_childHWND array.

Oh, I'm pretty certain we could get away with a single, manual reset event.
But hopefully a moot point.

> Ok. One thread per forked backend, right? Now that I think of it, this
> certainly sounds like a simpler solution :) I'll take a look at this one
> and see what it gives. Should give simpler code, yes.

Excellent! Want the code? Y!M me and I'll send an untested snippet over...

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

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