Ralph, On 2014/10/28 0:46, Ralph Castain wrote: > Actually, I propose to also remove that issue. Simple enough to use a > hash_table_32 to handle the jobids, and let that point to a > hash_table_32 of vpids. Since we rarely have more than one jobid > anyway, the memory overhead actually decreases with this model, and we > get rid of that annoying need to memcpy everything. sounds good to me. from an implementation/performance point of view, should we put treat the local jobid differently ? (e.g. use a special variable for the hash_table_32 of the vpids of the current jobid) >> as far as i am concerned, i am fine with your proposed suggestion to >> dump opal_identifier_t. >> >> about the patch, did you mean you have something ready i can apply to my >> PR ? >> or do you expect me to do the changes (i am ok to do it if needed) > Why don’t I grab your branch, create a separate repo based on it (just to > keep things clean), push it to my area and give you write access? We can then > collaborate on the changes and create a PR from there. This way, you don’t > need to give me write access to your entire repo. > > Make sense? ok to work on an other "somehow shared" repo for that issue. i am not convinced you should grab my branch since all the changes i made are will be no more valid. anyway, feel free to fork a repo from my branch or the master and i will work from here.
Cheers, Gilles
