Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add --bootstrap option to flux-start #990
@@ Coverage Diff @@ ## master #990 +/- ## ========================================== - Coverage 75.96% 75.95% -0.02% ========================================== Files 152 152 Lines 25946 25954 +8 ========================================== + Hits 19710 19713 +3 - Misses 6236 6241 +5
No time to look in detail right now - just quick comments:
I see at least one functions with no paramters prototyped like
The cleanup in here looks fine in general
It looks like
In general, is the pattern of bundling program state into a context struct, and passing that around to ancillary functions considered poor form, or was this a special case in this PR?
I tend to like avoiding the "global context" because it makes it more difficult to see which functions are using or require bits of the program state, so I have made this same choice (mistake?) many times. It would help if there was some other guidance as to why its usage here was unpalatable.
I also think having some guidance here would be useful. At least for a C API, I tend to like the style of passing around an API-level context as the opaque object between the client and API implementation.
We just had a mini discussion on this in our meeting. Let me see if I can summarize:
First we are talking about a single program context here, not an API context. The program context is effectively global if it's passed to every function in the program.
When the program context is passed as a parameter to functions instead of the one or two things in it that they actually need, then the cues about the extent of the function's inputs and outputs normally present in the parameter list are lost.
When state is placed in the context instead of being created/destroyed at the level of abstraction that it's needed, cues about when it can change and how it is used are lost.
Finally, (and this might be less unanimously agreed upon by the group), mallocing a context that is only used once confuses the casual reader of the code about its intended use. Can there be more than one?
Did I cover the main points?
These changes look good - merging.