-
-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor allocation of API context #4942
Conversation
Reduce number of alloc/free calls and simplify code Signed-off-by: Quincey Koziol <[email protected]>
Signed-off-by: Quincey Koziol <[email protected]>
Signed-off-by: Quincey Koziol <[email protected]>
Signed-off-by: Quincey Koziol <[email protected]>
Signed-off-by: Quincey Koziol <[email protected]>
* If a field has been set on the context but never read internally, <foo>_valid will be false | ||
* despite the context containing a meaningful cached value. | ||
*/ | ||
typedef struct H5CX_t { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An interesting point I hadn't considered but may be a problem in the future - the size of this struct may soon grow large enough to cause stack warnings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that too, and I checked the size: ~600 bytes currently. So, we should have a lot of margin for growth in the future. If it gets more than 10x bigger, we'll have to think about it again. :-)
…state Signed-off-by: Quincey Koziol <[email protected]>
Signed-off-by: Quincey Koziol <[email protected]>
Since each API context is local to a thread, use the stack to store the context instead of allocating & releasing it each time. This improves performance (slightly), reduces alloc/free calls, and eliminates the H5FL package from the push & pop operations, which helps simplify threadsafe operation. One effect of this change is that the H5VLstart_lib_state / H5VLfinish_lib_state API routines for pass through connector authors now require a parameter that can be used to store the library's context. It was probably a mistake to assume that these two routines would not do this previously, so this is essentially a bug fix for them. Some other minor things: * Added API context push+pop operations to cache tests (I'm not actually certain why this was working before) and a few other places * Cleaned up a bunch of warnings in test code (calloc args, mainly) * Made header file inclusions more standard in some source files
Since each API context is local to a thread, use the stack to store the context instead of allocating & releasing it each time. This improves performance (slightly), reduces alloc/free calls, and eliminates the H5FL package from the push & pop operations, which helps simplify threadsafe operation. One effect of this change is that the H5VLstart_lib_state / H5VLfinish_lib_state API routines for pass through connector authors now require a parameter that can be used to store the library's context. It was probably a mistake to assume that these two routines would not do this previously, so this is essentially a bug fix for them. Some other minor things: * Added API context push+pop operations to cache tests (I'm not actually certain why this was working before) and a few other places * Cleaned up a bunch of warnings in test code (calloc args, mainly) * Made header file inclusions more standard in some source files
Since each API context is local to a thread, use the stack to store the context instead of allocating & releasing it each time. This improves performance (slightly), reduces alloc/free calls, and eliminates the H5FL package from the push & pop operations, which helps simplify threadsafe operation.
One effect of this change is that the H5VLstart_lib_state / H5VLfinish_lib_state API routines for pass through connector authors now require a parameter that can be used to store the library's context. It was probably a mistake to assume that these two routines would not do this previously, so this is essentially a bug fix for them.
Some other minor things: