Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I was working on the
filexfer
PR again, I noticed some use of mutex-protected values outside of holding a mutex, and then not only do all the copies point to the same mutex, but also, because this mutex has to be set, the use of&sftp.Request{}
will always generate an invalid structure that will panic.I realize the pointer to mutex was there so that
*r2 = *r
would work and not generate an error duringgo vet
that a mutex is being copied, but this design unfortunately creates even more issues than it solved. I tried a bunch of different ways to keep the pointer, but still have&sftp.Request{}
not immediately be incurably invalid, but any solutions to this also require a mutex, which is the very problem we’re trying to avoid. We’re then stuck with having to copy values around the mutex. 🙁 A redesign might be necessary to avoid all mutex usage, I am unsure.Along with cleaning up the mutex usage, I linted a lot of
request.go
, breaking some lines up, paragraphing, and removing an unused parameter torunLs()
, so we can remove some unused path cleanup work, which then removes some imports in bothserver.go
andrequest.go
.