Skip to content
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

Add some missing const refs to CHostAddress params #3259

Merged
merged 4 commits into from
May 25, 2024

Conversation

softins
Copy link
Member

@softins softins commented Apr 2, 2024

Short description of changes

Refactoring: pass CHostAddress read-only parameters as const references instead of by value, except for signals and slots.

CHANGELOG: Refactor some CHostAddress parameters to be const references.

Context: Fixes an issue?

In the current code base, there are many instances where a CHostAddress is already passed as const CHostAddress&, but some instances where a CHostAddress object is passed by value instead. Depending on the platform, passing a reference may be more efficient than passing a whole object by value. This PR catches a few pass-by-value instances that can better be passed as const refs. However, when passing to signal or slot functions, pass-by-value is needed for thread safety, so those occurrences have not been changed.

The only functions that need to receive a non-const CHostAddress& are the ones for parsing addresses, as they pass the results of the parsing back to the caller via the reference.

Does this change need documentation? What needs to be documented and how?

Probably not.

Status of this Pull Request

Compiled fine and under test.

What is missing until this pull request can be merged?

Review, and running for a while on a server.

Checklist

  • I've verified that this Pull Request follows the general code principles
  • I tested my code and it does what I want
  • My code follows the style guide
  • I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
  • I've filled all the content above

@softins softins added the refactoring Non-behavioural changes, Code cleanup label Apr 2, 2024
@softins softins added this to the Release 3.11.0 milestone Apr 2, 2024
src/channel.h Show resolved Hide resolved
src/socket.cpp Outdated Show resolved Hide resolved
@pljones
Copy link
Collaborator

pljones commented Apr 16, 2024

Yep, I guess my only concern is if everything is a reference, then somewhere (untracked?) there's the original data... which could get freed and thus the references are no longer valid. There must be somewhere the actual value gets stored...

@softins
Copy link
Member Author

softins commented Apr 16, 2024

Yep, I guess my only concern is if everything is a reference, then somewhere (untracked?) there's the original data... which could get freed and thus the references are no longer valid. There must be somewhere the actual value gets stored...

I think the only concern would be if the receiving function is (relatively) long-lived, and the variable of which the reference is passed could change value in a different thread. For passing an unchanging value to a function that will just use it and return, passing a reference to the original parameter would be fine.

I'll do a pass through the modified calls to check there are no dodgy possibilities.

Copy link
Member

@ann0see ann0see left a comment

Choose a reason for hiding this comment

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

Not sure how much I can say here, but if it runs correctly, it should be fine? Yes, multithreading could be a possible source of incorrectness?

@softins
Copy link
Member Author

softins commented Apr 19, 2024

I'm off on holiday for a week. I'll pick it up again when I get back.

@softins softins marked this pull request as draft May 14, 2024 17:22
@softins
Copy link
Member Author

softins commented May 14, 2024

I've reverted most of the changes, specifically the ones relating to signals and slots. Connections from signals to slots can cross thread boundaries, so the receiver doesn't want to be referring to data belonging to the sender. So these should remain as call-by-value, ensuring the receiver has its own copy of the parameter. My original changes probably worked ok for a client, but would be liable to breakage in a server with multiple connections, particularly with multi-threading.

That leaves only a few changes remaining. I still need to double-check CChannel::PutAudioData(), but I think that one is ok. The other changes that remain are just immediate uses for initialisation, which is fine.

RecHostAddr doesn't need to be a class member, as it is only
used in CSocket::OnDataReceived(), so make it local.
@softins
Copy link
Member Author

softins commented May 14, 2024

Also removed a couple of unused members from CSocket and moved RecHostAddr from the class to OnDataReceived(), as it is only used in that function and doesn't need to persist.

@softins
Copy link
Member Author

softins commented May 14, 2024

I need to update the original PR description above, as it is now rather out of date.

@softins
Copy link
Member Author

softins commented May 15, 2024

I still need to double-check CChannel::PutAudioData(), but I think that one is ok.

Yes, CChannel::PutAudioData() is fine being changed to take a const ref. CServer::PutAudioData() already does so.

@pljones
Copy link
Collaborator

pljones commented May 15, 2024

Overall, there's no problems now, I think.

@softins softins marked this pull request as ready for review May 15, 2024 17:31
@pljones
Copy link
Collaborator

pljones commented May 16, 2024

Could you squash before the merge, please.

I'll see if I can get this onto my Servers and Directories. <edit>DONE</edit>

@softins softins requested a review from ann0see May 16, 2024 16:45
@ann0see
Copy link
Member

ann0see commented May 16, 2024

I may run it quickly ASAP to check for something obvious too but otherwise it's probably ok then.

@@ -41,7 +41,7 @@ using namespace recorder;
* Creates a file for the raw PCM data and sets up a QDataStream to which to write received frames.
* The data is stored Little Endian.
*/
CJamClient::CJamClient ( const qint64 frame, const int _numChannels, const QString name, const CHostAddress address, const QDir recordBaseDir ) :
Copy link
Member

@ann0see ann0see May 25, 2024

Choose a reason for hiding this comment

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

Please check for bugs here too.

I tested running the server on macOS and it needed multiple tries to show up as directory. The directory did not show up for a local client if a path for recordings is set. It may not be related and needs more investigation (test with a path that is not writable).

It seems as if on 3.10.0 the directory shows up instantly.

Copy link
Member

Choose a reason for hiding this comment

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

Also the Now a directory text doesn't show up in green:
Now a directory

Copy link
Member

Choose a reason for hiding this comment

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

Hmm. Ok. Current main also shows this issue. Seems to be unrelated.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, if this problem behaviour is repeatable post-3.10.0 but not in 3.10.0, it needs to be raised as a new issue. Maybe need to bisect to find where it was introduced?

Copy link
Member

Choose a reason for hiding this comment

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

Issue opened

Copy link
Member

@ann0see ann0see left a comment

Choose a reason for hiding this comment

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

Otherwise everything seems ok (testing to connect to server, listening, audio goes both ways)

@softins softins merged commit bb1639a into jamulussoftware:main May 25, 2024
11 checks passed
@softins softins deleted the const-ref branch May 25, 2024 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Non-behavioural changes, Code cleanup
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants