Bruce Momjian:
> > Tom Lane:
> > > Per Jan's comment, there is no need to mess with the existing
> > > datastructure. I'd think more of *copying* the dllist into some array
> > > in shared memory. This is code that would only need to exist in the
> > > Windows port.
> >
> > (I thought Jan was referring to the PGPROC struct)
> >
> > This just seems a little odd to me. I mean, they are going to be
basically
> > identical (they'll even use the same struct!).
>
> Seems you should use an array of "struct bkend" or "Backend" as storage
> in shared memory. I think the problem with Dllist is that it is
> dynamically allocated and I don't see how that could be done cleanly in
> shared memory. I think that's why the array idea seems best.
I wasn't suggesting that we somehow put the Dllist in shared memory. I was
advocating completely replacing the BackendList dlllist with this array,
under both Win32 and *nix case. (Is what I've been saying sound different in
this light?)
AFAICS, dumping the BackendList dlllist, and just completely replacing it
with "PidCancel[]" in shared memory would be a pretty small hit, and give us
the same code under *nix + Win32.
> Looking up they key would have to be different for fork and fork/exec.
Only if we choose to have this new PidCancel array, in addition to the
existing BackendList, which looks to me to be entirely redundant.
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>
