-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
proposal: os: make the internal lockedfile package public #33974
Comments
Why not use the exported version at https://godoc.org/github.com/rogpeppe/go-internal? :) |
Hey @mvdan, 🙂 here are a few reasons why I didn't go with it:
|
I'm not sure why that is, perhaps @rogpeppe or @myitcv can answer. Have you looked at https://godoc.org/github.com/rogpeppe/go-internal/lockedfile? That seems like a public, higher-level version of it. That aside, sure, there are some upsides to having this in the standard library. But I think the downsides are generally greater:
I think a far better proposal would be to include this in one of the official external repos, like |
lockedfile fits right to our usage and Yes, I agree this should probably be in an |
CC @bcmills |
At this point we've been using Then the question is where to put it: |
It's right at the intersection of edit: regroup them both under |
@azr, If folks discover other interesting use-cases for |
Given that the author of filelock says it is not ready to be exported, it seems like this is a likely decline. Leaving open for a week for final comments. |
To be clear: I support making the |
That's fine by me 🙂. I think I'll put it in |
I misunderstood. Thanks for the clarification, @bcmills. Removing the FinalCommentPeriod label. |
I don't think we are ready to add lockedfile to the standard library. It is a peculiar set of functions that does not really line up with the usual things in either os or io. Maybe it would be OK in x/sync but maybe it would be better to start in x/exp to understand if the API needs any adjustments. If we are going to add a new public package (even in x/exp), I think the next step would be for someone to write a proper proposal doc laying out the API and explaining the decisions, get comments, and so on. @azr, do you want to do that? |
@rsc gotcha ! Yes I want to ! Where should such a proposal doc be written ? Is there a template for that ? |
Putting proposal on hold for design doc. |
Hello there; I created the proposal ( first ever ! ) here golang/proposal#21; I hope it's good enough please feel free to give feedback 🙂 🙂 ! |
It's in the "incoming" list. We move proposals from "incoming" to "active" as we have bandwidth to handle them. See https://go.googlesource.com/proposal/+/refs/heads/master/README.md . |
@ianlancetaylor I had missed that bit of information. Thank you |
any update on making lockedfile package public? |
Some the details seem buried... The proposal process completed and landed the proposal on Mar 10, 2020: https://github.com/golang/proposal/blob/master/design/33974-add-public-lockedfile-pkg.md The proposal looks good. It is unclear how / who to involve to move past proposal. Any insight @azr ? Happy to help if there is a need. |
@kensipe This proposal has still not been accepted. I'll put it on the list for faster consideration. |
vuln/cmd/govulncheck could also make use of this library. |
Is it going to be public anytime soon? |
The logic here is racy since multiple endtoend tests can create the file at around the same time and allocate the same base port. This then leads to flaky failing endtoend tests since not all ports can be used. Even with the listening check later on, this is still racy because the listen check might run at a later point still trying to allocate the same port for the same service in different endtoend test. This copies the Go filelock implementation, but only for unix systems since that's the only supported platform for Vitess. Go has a proposal open to make filelock available, but that is still pending in golang/go#33974. Once that is resolved, we can remove our copy of the implementation. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
* Fix race in determining start port for cluster The logic here is racy since multiple endtoend tests can create the file at around the same time and allocate the same base port. This then leads to flaky failing endtoend tests since not all ports can be used. Even with the listening check later on, this is still racy because the listen check might run at a later point still trying to allocate the same port for the same service in different endtoend test. This copies the Go filelock implementation, but only for unix systems since that's the only supported platform for Vitess. Go has a proposal open to make filelock available, but that is still pending in golang/go#33974. Once that is resolved, we can remove our copy of the implementation. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> * Change range of dynamic ports to not collide with tests Next to the previous commit which fixes the race base port computation, we also need to avoid collisions between ephemeral outgoing ports to 127.0.0.1 and the listening ones. The problem is that we set 1024 as the first ephemeral port, but that means we can collide and trigger flaky tests with all the tests that allocate a server port as well. Given we start allocating server ports now starting at 6700 for endtoend tests and we allocate in blocks of 200, we have room for 75+ concurrent endtoend tests which should totally suffice. We still have a range of 40+ ephemeral ports which should still be sufficient as well. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Running two instances of the server which share the same directory (e.g. default configuration `/tmp/nats/jetstream') will corrupt each other. We mitigate by creating an empty file called LOCK in the directory and then acquire a posix `flock(2)` on it; a common pattern. Note this is not inherently cross-platform without golang/go#33974 Signed-off-by: Jason Volk <jason@zemos.net>
An internal filelock pkg can be found here:
https://pkg.go.dev/cmd/go/internal/lockedfile/internal/filelock
A few projects are implementing file locking [1] but they do not seem to be maintained and I think they are not as nice as the internal filelock pkg I mentioned before. As a result some projects are doing their own version of it [2].
I suggest we make the filelock pkg public as I think this could be beneficial to the mass.
I'd be glad to do it given some pointers, like where to put it ?
Thanks !
[1] File lock projects:
https://github.com/gofrs/flock
https://github.com/MichaelS11/go-file-lock
https://github.com/juju/fslock
[2] Projects that implement their own file locking:
terraform
boltdb
The text was updated successfully, but these errors were encountered: