Hello gophers,
We plan to issue Go 1.24 RC3 during US business hours on Wednesday,
February 5.
The Go 1.24 RC3 release will include a PRIVATE security fix for a problem
that is only present in previous Go 1.24 RC releases, covering the
following CVE:
-
CVE-2025-22867
Following our secu
That’s true. I should have mentioned, that there are many test cases and
several handlers involved in the real code. I tried to boil it down to a
simple snippet reproducing the issue (https://sscce.org/), and some context
got lost on that path. Let me explain a little more:
I test a binary (as par
On Friday, January 31, 2025 at 1:58:39 PM UTC-5 Michael Knyszek wrote:
I think I got a little overzealous with my opinions, it wasn't my intent to
be particularly prescriptive. I also did not get the impression that you
were suggesting the memory model should be different.
Bottom line: yes, i
It's not clear from your example why you're writing to the "response"
variable in the first place. One simple solution would be to create the
test server within the subtest, then there's no sharing at all.
There are only a few ways to fix a data race and they don't really depend
on the specific
I think I got a little overzealous with my opinions, it wasn't my intent to
be particularly prescriptive. I also did not get the impression that you
were suggesting the memory model should be different.
Bottom line: yes, it's possible to implement but more fragile in Go due to
the less-thoroughly-
To clarify, my op was to understand if this could be done in Go, which Bruno
showed it can, and know I’d like to know why the race detector is not
complaining…
I wasn’t making any attempt at creating a more specified Go memory model. It is
what it is.
> On Jan 31, 2025, at 12:09 PM, robert eng
This is a well-known pattern (use an atomic counter to check if anyone else
modified some data in a critical section and retry or fall back if it
happened), but as the extensive Java docs imply, any such abstraction is
going be fairly leaky. Java has a very thoroughly defined memory model that
I believe you are most likely right about the TryLock(0 not being needed
but I am not 100% sure. I guess eventually I will investigate it.
I am also puzzled by the race detector behavior here, FWIIW. :)
And no worries, this sounded like something useful to write. It goes
without saying but feel f
But the lock shouldn’t be necessary I don’t think? The atomic read provides a
happens before relationship - which is why removing it didn’t change anything.
I am just surprised the race detector does not complain - given my knowledge of
how the race detector works it seems it should.
Thanks for
I did not look at the java code (I went for the description on the link you
posted).
The idea in TryOptimisticRead() is that the TryLock() helps avoiding
reordering/cache effects. Consider this:
Reader 1 calls TryOptimisticRead() and reads the stamp (let's say it's 100).
Writer acquires the writ
Your code seems substantially different than the Java implementation. For
instance, in your tryOptimisticRead(), you take a lock - the Java version has
no locking in that method (on a volatile, aka atomic read) - although I am not
sure why you are taking the lock.
func (sl *StampedLock) TryOpti
I wonder if the TryLock() call in the TryOptimisticRead() (used here as an
acquire barrier/half fence) is making the race detector happy enough.
-Bruno
On Fri, Jan 31, 2025 at 11:51 AM Bruno Albuquerque wrote:
> Ops. There was a bug due to left over of me testing. Here is a fixed
> version:
>
The code you provided doesn’t compile - wrong link?
> On Jan 31, 2025, at 10:31 AM, Bruno Albuquerque wrote:
>
> This seemed expected to me but I went ahead and created a Go implementation
> (which might not be 100% correct so take it for what it will) and I was
> surprised that the race detec
Ops. There was a bug due to left over of me testing. Here is a fixed
version:
https://go.dev/play/p/UuIWVlV0UTN
Also, don't try to run in the playground as this runs forever (it could be
changed but I am lazy).
-Bruno
On Fri, Jan 31, 2025 at 11:31 AM Bruno Albuquerque wrote:
> This seemed ex
This seemed expected to me but I went ahead and created a Go implementation
(which might not be 100% correct so take it for what it will) and I was
surprised that the race detector did not really complain about anything.
https://go.dev/play/p/R1alMCc-xN9
-Bruno
On Fri, Jan 31, 2025, 6:13 AM Rob
The documents are too simple to explain clearly on anything.
Besides the eating/chomping behavior, does an item include the
space/newline following it?
Either answer will not satisfy the behavior of the following code,
by either answer, there should one case reports an error.
https://go.dev/play/
I meanwhile found a way by using a sync.Map for the responses like this:
https://go.dev/play/p/KMZ7v63Ht6t
thanks - Chris
Am Fr., 31. Jan. 2025 um 09:06 Uhr schrieb Chris Burkert <
burkert.ch...@gmail.com>:
> Dear all,
>
> I have the following test: https://go.dev/play/p/fQgnvbomlhz (you have to
Hi,
Do you think it is possible to implement a stamped lock in Go
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/StampedLock.html
?
It would seem that the Go race detector would always report the “optimistic
read” mode as a data race?
(The docs state for Java that the va
Dear all,
I have the following test: https://go.dev/play/p/fQgnvbomlhz (you have to
run it locally as it does not work in the playground and it expects
/usr/bin/curl as I was not able to reproduce the race using http.Get()).
When I run this with *go test -race -v -count=1 .* I get the following r
19 matches
Mail list logo
