Hi
On Thu, 21 Mar 2024 at 19:23, 'Christian Stewart' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> When sending Read() via an RPC call or traversing locks, it is
> significantly faster to return EOF in the same call as returning the rest
> of the available data, than to call Read a sec
Wow, i am from other language and i thought `string` is immutable or
something like that, so thread-safe for this operation. learned something
new!!! Thanks
On Thursday, March 21, 2024 at 11:42:24 PM UTC+8 Ethan Reesor wrote:
> I hadn't used the race detector before. I do see a race warning for
TBQH the word "mutable" doesn't make a lot of sense in Go (even though the
spec also calls strings "immutable").
Arguably, *all* values in Go are immutable. It's just that all *pointers*
in Go allow to modify the referenced variables - and some types allow you
to get a pointer to a shared variable,
I don't really get it.
The current documentation says that bespite err!=nil, some data may be read
(n!=0).
If one obeys this rule, then it will consume the data, then handle the
error.
If we change then io.Reader's documentation (and all std lib
implementations)...
Ok, now I may be understand:
And as Axel's own reproducer shows, even having two threads reading and
writing the same *variable* which points to a string can result in
indeterminate behaviour, since a string is really a struct containing two
parts (a pointer and a len). You're not mutating the string itself, but
you are u
On Mon, Mar 25, 2024 at 3:47 PM 'Brian Candler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> And as Axel's own reproducer shows, even having two threads reading and
> writing the same *variable* which points to a string can result in
> indeterminate behaviour, since a string is really
Sorry I might've been to terse in my previous email.
On Mon, 25 Mar 2024 at 15:19, Tamás Gulácsi wrote:
> I don't really get it.
> The current documentation says that bespite err!=nil, some data may be
> read (n!=0).
> If one obeys this rule, then it will consume the data, then handle the
> erro
Or to be perhaps more precise: This view can be useful to understand the
observed behaviour: A string is two words which are updated non-atomically,
hence one read might observe the write of the length separately from the
write of the data.
But to determine the *correctness* of the program, any co
Hello,
// main.go
package main
import (
"sync"
"time"
)
func main() {
var wg sync.WaitGroup
go lolsleep(&wg)
wg.Add(1)
wg.Wait()
}
func lolsleep(wg *sync.WaitGroup) {
wg.Done()
time.Sleep(3 * time.Second)
}
go vet main.go
Why isn't go vet complaining that wg.Add is happening after the us
On Mon, Mar 25, 2024 at 12:46 PM Nikhilesh Susarla
wrote:
>
> Why isn't go vet complaining that wg.Add is happening after the usage. Where
> as the document clearly says increment and then use it as the wg.Done may be
> called an can run into negative/deadlock
First, please send Go code as plai
On Sat, Mar 23, 2024 at 11:58 AM Wen Wei wrote:
>
> Lock always calls runtime_SemacquireMutex(&m.sema, queueLifo, 1) ->
> semacquire1 when in starving mode.
>
> ```go
> // src/runtime/sema.go
> func semacquire1(addr *uint32, lifo bool, profile semaProfileFlags,
> skipframes int, reason waitReaso
On Sat, Mar 23, 2024 at 12:20 PM Jeffery Carr wrote:
>
> While doing that and looking at the code, there are lots of interesting and
> good things in internal/ that can't be used. While I think I understand the
> reasons for internal/, I wonder if the GO compiler might be more immune to
> those
Please don't use screenshots for plain text. Screenshots are hard to read
and we can't copy/paste the text in the image.
The error says it can't connect to 172.21.0.1 port 5672. Do you perhaps
have the port numbers reversed in your "yml compose file"? Is the IP
address correct?
On Mon, Mar 25, 20
13 matches
Mail list logo
