Skip to content

Conversation

@PSUdaemon
Copy link
Contributor

We should remove ink_atomic and replace it with std::atomic.

zwoop
zwoop previously approved these changes Oct 6, 2017
Copy link
Contributor

@zwoop zwoop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're the best, really you should come to Tokyo to beat the QUIC code into submission too!

@PSUdaemon PSUdaemon force-pushed the remove_ink_atomic branch 2 times, most recently from cd2f367 to 8ee83df Compare October 6, 2017 18:50
@dragon512
Copy link
Contributor

Oh no! build failure on Linux!!!

@dragon512
Copy link
Contributor

We might need to add
-std=c11

This headers should exist for gcc 4.9 or better

@SolidWallOfCode
Copy link
Member

If it's just plugins written in C that are the problem, I say put the old ink_atomic... in a separate header file named c99_atomics.h or some such and use it only in C plugins.

@PSUdaemon PSUdaemon force-pushed the remove_ink_atomic branch 2 times, most recently from 4f1f571 to 6a3b324 Compare October 6, 2017 22:16
bryancall
bryancall previously approved these changes Oct 9, 2017
TSDebug(PLUGIN_NAME, "ref_count is %d", _ref_count);
if (1 >= ink_atomic_decrement(&_ref_count, 1)) {
TSDebug(PLUGIN_NAME, "ref_count is %d", (int)_ref_count);
if (1 >= _ref_count--) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought this might be a problems, but it isn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which part? I am changing that to a C++ static_cast for @SolidWallOfCode.

@bryancall
Copy link
Contributor

[approve ci autest]

Copy link
Contributor

@jpeach jpeach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PSUdaemon IMHO we should always use fetch_add and fetch_sub and never use the operators. The member functions clearly indicate the semantics to the reader and are easy to search for and find usages of. They also make it easier later to alter the memory consistency argument.

bryancall
bryancall previously approved these changes Oct 11, 2017
dragon512
dragon512 previously approved these changes Oct 20, 2017
@PSUdaemon
Copy link
Contributor Author

@jpeach if I go down that path for the inc/dec should I also do it for load/store? Basically every use of a std::atomic will require some modification. To me this kinda defeats the purpose of std::atomic. Just calling a method instead of wrapping it in a function.

@PSUdaemon
Copy link
Contributor Author

I know there are a ton of failures right now, but I wanted @jpeach to look at what I meant with the load/store. Here is an example.

@jpeach
Copy link
Contributor

jpeach commented Nov 2, 2017

@PSUdaemon I think that atomic ops deserve to be made very explicit in the code, even at the cost of extra typing ;)

@bryancall
Copy link
Contributor

This PR hasn't been updated in more then 2 months and I am closing out PRs that haven't had any updates. Please feel free to reopen if want to update it.

@bryancall bryancall closed this Feb 7, 2018
@zwoop zwoop removed this from the 8.0.0 milestone May 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants