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

Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to