At 10:26 AM 7/29/2004, William A. Rowe, Jr. wrote: >If you changed worker_score, it would still have broken (or if you change >balancers in the future.) Agents reviewing the scoreboard are presuming >scoreboard_entry *psb can be accessed as psb[0..n] and that -will- be >broken with any size/alignment change to the struct. > >E.g. [...?]
we have individual element accessors, but older style code presumes it can loop through the array of individual worker threads/procs. Adding another element to worker_score would break the starting offset of the members psb[1..n]. Although we create the pointer-pointer logic in the children to avoid this, it's still possible that the code would break some modules. I can't envision a case where any of the scoreboard entries are allocated outside of our scoreboard.c code. At 11:01 AM 7/29/2004, Mladen Turk wrote: > I was afraid you've gonna said that. Those 3rd party... :). > How about adding extra data to the end of the entire scoreboard withouth > touching any existing structs or data? > It will require an extra copy on child_init, but there will be no > compatibility issues, thought. You aren't changing worker_score so this isn't an issue. The patch already creates (new) a fourth lb_score array. Bill
