Re: [go-nuts] Correct use of bufio.Reader

That code seems to be correct (except that you might want a `if err != nil { break }` in there). I would say the reason you get empty messages is because the other side is sending you empty messages. On Sun, Feb 5, 2023 at 10:01 PM TH wrote: > Hey, > > I have a TCP client which reads data from s

Re: [go-nuts] please continue High Sierra mac OSX support

Hi Ian, I too would like to see support for High Sierra continue. Here is some additional information to support the hardware argument. Currently on eBay there are over 300 Mac Minis from mid 2010 and mid 2011 and a quick eyeball makes it seem like they can be had for less than US$100. (And th

Re: [go-nuts] Re: Go+Windows+Audio

Alberto, I'm using Docker for cross-compiling my cgo apps. One project of mine ( remoteAudio ) requires portaudio (and a couple of other C libraries like pkgconfig and libopus). You can find the cross-compilation chain at github.com/dh1tw/remoteAudio-xcompile

[go-nuts] Correct use of bufio.Reader

Hey, I have a TCP client which reads data from server. Each message is ; delimited. I wonder what's the correct way to use bufio.Reader, as I'm getting empty messages. reader := bufio.NewReader(conn) for { msg, err := reader.ReadBytes(59) // ; as delimiter if err == nil { fmt.Pr

[go-nuts] Profile Guided Optimisation

I've not seen much talk about the public preview of Profile Guided Optimisation available in v1.20. I'd not even heard that this feature was being planned until an acquaintance mentioned it this evening. I read the blog and tried it out. Very simple feature to use. I'm getting 10% performance i

Re: [go-nuts] Re: Upgradable RLock

On Sun, Feb 5, 2023, 4:34 AM Juliusz Chroboczek wrote: > >> I took some time to put this to a test. The Go program here > >> https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the > >> lock - but a large % of runtime holding the lock. > > > Thanks for the benchmark. You're right: if

Re: [go-nuts] Drain channel on demand without busy looping?

On Sun, Feb 5, 2023 at 5:12 PM cpu...@gmail.com wrote: > Would that still busy-loop? Are there better patterns? for range q.data {} iff the sending side properly closes the channel. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To u

[go-nuts] Drain channel on demand without busy looping?

I have the requirement of being able to drain a channel, i.e. make sure that downstream processes all data currently being sent. One possible pattern is something like for{ select{ case <-q.data: default: } } where the default branch could indicate that channel has been drained. My concern is,

Re: [go-nuts] Upgradable RLock

The article is very suspect. In the first section "A simple implementation" the code is badly broken. You can't get a reader lock if the writer has the write lock - which the code doesn't test: func (l *ReaderCountRWLock) RLock() { l.m.Lock() l.readerCount++ l.m.Unlock() } A single writer RWM

[go-nuts] Re: Upgradable RLock

>> I took some time to put this to a test. The Go program here >> https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the >> lock - but a large % of runtime holding the lock. > Thanks for the benchmark. You're right: if you have hundreds of > goroutines doing nothing but acquiring a re