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>

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