On Wed, Apr 06, 2022 at 07:16:43PM +0000, Jacob Champion wrote: > I assumed that we would follow the existing model of "(de)serialize a > whole struct", rather than pulling it apart into many separate keys. If > it got too complicated then we could consider introducing a > SerializedParallelProcInfo struct like some of the other functions do. > Maybe that wouldn't work so well if many of the fields are strings? > > Is there a significant cost to changing this later, if one approach > turns out to be wrong?
I don't think this is going to be an issue as long as we don't change the definitions of MyParallelProcInfo, Port or PARALLEL_KEY_* in the stable branch. My guess is that we are fine to switch to one approach or the other as this is just some internal communication logic between the parallel leader and its workers. What is the feeling of others about this patch and the introduction of ParallelProcInfo (or ParallelPortInfo?) to store the authn coming from Port? The feature freeze is very close. -- Michael
signature.asc
Description: PGP signature