-
Notifications
You must be signed in to change notification settings - Fork 844
Remove TSDebug() and TSIsDebugTagSet() TS API functions. #10390
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
Conversation
83bd148 to
cfa30c9
Compare
cc3bd63 to
1fd211d
Compare
|
@cmcfarlen this is passing CI now. |
1fd211d to
14116f4
Compare
|
@cmcfarlen It's successfully rebased. |
cmcfarlen
left a comment
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.
This is mostly mechanical. I am concerned that the esi plugin will generate a lot of tags for the tag registry. Can you explain how that works?
|
|
||
| #define PLUGIN_NAME "hello_world" | ||
|
|
||
| DbgCtl dbg_ctl{PLUGIN_NAME}; |
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.
Do you want to establish the convention of putting these in anonymous namespaces here?
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 think it's not that simple. If I add an anonymous namespace, check_ts_version() probably belongs in it also. But, if I make such changes consistently, in all the files I'm touching, it will likely double the size of this PR. I get a lot of surprising push back in reviews on this project. For example, push back that seems to dispute the value of RAII. Which makes me feel like adding any sort of cleanup risks adding further delay to merging PRs.
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 just mean in this example, since folks tend to copy pasta examples. If we want to prefer anonymous namespaces, having that in the example will help with proliferation.
| { | ||
| extern DbgCtl dbg_ctl; | ||
| } | ||
| using namespace protocol_ns; |
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 know this is just an example, but putting this using namespace in a header might lead to user astonishment.
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 see your point, but what do you see as the better alternative?
TS developers must steel themselves to endure astonishment, and not in a good way.
|
|
||
| extern DbgCtl cache_promote_dbg_ctl; | ||
|
|
||
| #define DBG(...) Dbg(cache_promote_dbg_ctl, __VA_ARGS__) |
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.
Why is this plugin converted with a macro rather than Dbg?
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 think I did this before I thought of the other approach with using namespace.
plugins/esi/esi.cc
Outdated
| input_type(DATA_TYPE_RAW_ESI), | ||
| packed_node_list(""), | ||
| gzipped_data(""), | ||
| dbg_ctl{createDebugTag(DEBUG_TAG, contptr)}, |
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.
Won't this insert a lot of tags into the registry? How often is ContData instantiated?
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.
If you create multiple DbgCtl instances for the same tag, they will all point to the same entry in the registry map. In any case, I think each instance of this continuation class will have a unique debug tag. So there's a net increase, per class instance, of 8 bytes for the pointer in the DbgCtl, plus the overhead of an additional std::map entry.
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.
It looks like a new ContData instance is created per transaction that this plugin handles. Since the tag is created using the address of the contptr instance, I feel like there is a good chance that there will be a lot of additional tags due to this.
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.
But my changes don't increase the number of instances of ContData. I see the issue, but what can I do about it?
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.
It seems like these tags are generated to add correlation context to the log statements and not as a way to filter them with the tagging mechanism. One idea would be to move this context from the tag name into the log message and have a fixed number of dbgctl tags.
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.
But does that really belong in this PR? The change you suggest would reduce memory use in the existing code. It can't clearly be claimed it's addressing an issue that I created.
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.
Correct me if I am wrong, but as I understand it, any tags created by DbgCtl instances will only be cleaned up when the Registry destructor is called. The DbgCtl destructor only decrements the reference counter. Therefore, if some code (i.e. this very esi plugin), creates a new DbgCtl instance per ATS transaction, the size of the tag registry will grow unbounded.
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.
OK, valid point.
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.
Fixed
Replace with Dbg() and DbgCtl::on(). This required extensive changes to the ESI plugin unit tests. Doc changes were also necessary. The redirect_1 example plugin is changed to illustrate how to implement debug trace output in a plugin that can compile and run with either these ATS10 changes or for older versions of ATS.
_No_tag_dummy is changed to a static member function that returns a function-local static variable. Also, to avoid changing gold files with debug output, diags.show_location is disabled for the Au tests that test for debug output using gold files.
14116f4 to
c7b83b6
Compare
c7b83b6 to
39535d7
Compare
cmcfarlen
left a comment
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.
Nicely done. Thank you!
Replace with Dbg() and DbgCtl::on(). This required extensive changes to the ESI plugin unit tests.
Doc changes were also necessary.
The redirect_1 example plugin is changed to illustrate how to implement debug trace output in a plugin that can compile and run with either these ATS10 changes or for older versions of ATS.