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
