Re: New win32 signals patch (3)

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander' <mha(at)sollentuna(dot)net>, 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 09:55:28
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F2CE@harris.memetrics.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

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

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Claudio Natoli 2004-02-04 11:01:26 Re: New win32 signals patch (3)
Previous Message Magnus Hagander 2004-02-04 09:03:12 Re: New win32 signals patch (3)