Improve ref count semantics on http message #359
Conversation
| * Acquire a hold on the object, preventing it from being deleted until | ||
| * aws_http_message_release() is called by all those with a hold on it. | ||
| * | ||
| * This function returns the passed in message (possibly NULL) so that acquire-and-assign can be done with a single |
There was a problem hiding this comment.
It feels a program error to acquire on a null message to me.
There was a problem hiding this comment.
Well that's the ref count semantics that I believe we should use and that's the way acquire works in all of the ref count semantics that I have added which is a lot. The point is to make using acquire/release not require conditional logic. If something should be non-null feel free to check it. But acquire/release should not crash and should have the semantics that this uses. Same reasoning as the uh private PR from this afternoon:
acquire_and_assign is a single statement regardless of nullity:
thing->ref = aws_something_acquire(some_ref);
release_and_assign(NULL) is also a single statement, regardless of nullity:
thing->ref = aws_something_release(thing->ref);
We are pushing the conditional checks into acquire/release so that users do not have to do them. If something should be non-null that isn't acquire/releases concern; it should be checked elsewhere. This follows the same reasoning as to why every *_destroy() function written in the last 3-4 years checks for null as the first thing. In that case, it allows your destroy functions to tear down partially built objects (or ones with optional references) without checking null on everything.
4 participants
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.