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

['Axel Wagner' via golang-nuts]

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 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.Printf("%v\n", string(msg))
> }
> }
>
> So sometimes I will get a msg that's only ";". I wonder if bufio.Reader
> can be re-used as I do it on my for loop? Or are there any handy packages
> that I could use to parse the ";" delimiter?
>
> I tried to write my own parser, but somehow bufio.Reader is like 3-4x
> faster even I thought I had an optimized code.
>
> Thanks
> - TH
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e4c474c8-87b0-400d-9576-c26ad54f585en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF24y8OvEkD9%3DnkMAmFtE8Mqhhia4wY-9TYnxm4DqJfCQ%40mail.gmail.com.

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

[Mike Schinkel]

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 that doesn't count MacBooks or iMacs.) They are an excellent 
machine for someone who can't afford a new Mac to buy and needs to set up 
as a home server for macOS-related work.

There are numerous videos on YouTube about using 2010 and 2011 Mac Minis 
(and even more about using mid 2012):

https://youtu.be/gTqlVdSfGK0
https://youtu.be/iqn2xGt3sos
https://youtu.be/9yFewmhDymc

Anyway, if GoLang stops supporting this hardware then these would no longer 
viable for testing and/or running newer Go code on macOS, albeit an earlier 
O/S version.

Anyway, I know that a lot has to be taken into consideration but I wanted 
to add more details about how much hardware like this is available and what 
people might be using it for.

-Mike
P.S. I'll follow up over on the ticket, too.
On Friday, February 3, 2023 at 1:36:03 PM UTC-5 Ian Lance Taylor wrote:

> On Fri, Feb 3, 2023 at 9:42 AM Jason E. Aten  wrote:
> >
> > Primarily the argument is that High Sierra is the most stable version of 
> OSX,
> > and thus preferred by those who highly value stability and reliability. 
> It is also the only
> > version supported on older hardware, such as my 2015 mac book pro. These 
> mac books
> > have superior keyboards and better access to USB ports and HDMI ports. 
> They are readily available on
> > the used market for testing purposes. Just last week I bought my wife 
> one for only $320.
> > There are tens if not hundreds of listings on ebay.
>
> Thanks. Required for older hardware seems like a valid reason to me.
>
> Please comment on https://go.dev/issue/57125, which is the proposal
> for dropping High Sierra support.
>
> Ian
>
>
> > On Fri, Feb 3, 2023 at 12:34 PM Ian Lance Taylor  
> wrote:
> >>
> >> On Fri, Feb 3, 2023 at 8:34 AM Jason E. Aten  wrote:
> >> >
> >> > The Go 1.20 release notes say:
> >> >
> >> > > Go 1.20 is the last release that will run on macOS 10.13 High 
> Sierra or 10.14 Mojave. Go 1.21 will require macOS 10.15 Catalina or later.
> >> >
> >> > This is sad to hear, since High Sierra is the preferred (most stable) 
> available mac operating system.
> >> >
> >> > Please consider continuing to support High Sierra in future Go 
> versions.
> >>
> >> Our general guideline is that we stop supporting an operating system
> >> when that operating system is itself no longer supported. According
> >> to Wikipedia, Apple stopped supporting High Sierra in 2020, so
> >> presumably people should be moving off it. It's also going to be
> >> steadily harder for us to test it. What's the argument for us
> >> continuing to support it?
> >>
> >> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a3e67455-c433-49bc-8130-0cec5c87b502n%40googlegroups.com.

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

[Tobias Wellnitz]

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. For Windows, have a look at the
windows-amd64

folder.

I have also written a companion blog post about cross compiling CGO projects
.

Best regards,
Tobias

Am So., 5. Feb. 2023 um 01:13 Uhr schrieb alberto sansegundo <
albertosansegundo...@gmail.com>:

> Hello, im now facing this same problem, did you managed to solve it?
>
> El lunes, 7 de noviembre de 2016 a las 18:16:37 UTC+1, d.sh...@gmail.com
> escribió:
>
>> Hi all.
>>
>> I've tried to get access to Windows audio from Go program but failed.
>> That I did below:
>> 1. Downloaded and built Portaudio (it's open audio I/O library
>> http://portaudio.com/). So I've built that with Visual Studio and got
>> .dll file.
>> 2. Downloaded Go wrapper for Portaudio - (
>> github.com/gordonklaus/portaudio )
>> 3. Made simple Go file with an example from wrapper above to test.
>> 4. Go build.
>>
>> So Go couldn't build that. As far as I understand that's tried to build
>> the portaudio from source with cgo. I've installed MinGW (gcc for Windows)
>> and pkg-config but last one can't find portaudio-2.0.pc file. Once I've
>> renamed portaudio-2.0.pc.in to portaudio-2.0.pc however it shows gcc
>> error: "gcc: error: @THREAD_CFLAGS@: No such file or directory". So I
>> think it was stupid idea.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8c77da1b-2a5c-4222-bb04-d84347c1a4e0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKrpA_5TxWGz_mZ9H83G1L3NdfN920J9reb_cAgspMOP7wM4ZQ%40mail.gmail.com.

[go-nuts] Correct use of bufio.Reader

[TH]

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.Printf("%v\n", string(msg))
}
}

So sometimes I will get a msg that's only ";". I wonder if bufio.Reader can 
be re-used as I do it on my for loop? Or are there any handy packages that 
I could use to parse the ";" delimiter?

I tried to write my own parser, but somehow bufio.Reader is like 3-4x 
faster even I thought I had an optimized code.

Thanks
- TH

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e4c474c8-87b0-400d-9576-c26ad54f585en%40googlegroups.com.

[go-nuts] Profile Guided Optimisation

[stephen.t....@gmail.com]

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 increase, which is 
honestly amazing.

Well done to the team responsible. This is a game changer for me.

Stephen Illingworth

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cbc80346-6b12-4a6b-8046-39d08b0817c0n%40googlegroups.com.

Re: [go-nuts] Re: Upgradable RLock

[Ian Lance Taylor]

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 you have hundreds of
> > goroutines doing nothing but acquiring a read lock, then an RWMutex
> > can be faster.  They key there is that there are always multiple
> > goroutines waiting for the lock.
>
> Could you please explain that?  You previously implied that the
> required atomic operation is going to make the difference between the
> two kinds of mutex irrelevant, why does the argument not apply here?
>

If there are enough concurrent lockers to overwhelm the plain mutex spin
lock, then the read-write mutex will work better.  My argument is that in
real programs that is an unlikely case if the lock is held for a short
period of time.

Ian

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXoO1ajdM-wXoFiqR3joxzxiHOe2vXgya43xAs2%3Dd-xJw%40mail.gmail.com.

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

[Jan Mercl]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VAiRkF7PEZnOq50UnOJf%3D-eptD-hJ9WDaBOC0AvnL1zQ%40mail.gmail.com.

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

[cpu...@gmail.com]

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, that this would create a busy loop on the default branch even 
when not trying to drain the channel.

I could use an atomic for checking if work should be done in default (i.e. 
signal channel has been drained).

Would that still busy-loop? Are there better patterns?

Cheers,
Andi

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4887e28d-bcfb-4f49-9450-00e56e00be55n%40googlegroups.com.

Re: [go-nuts] Upgradable RLock

[ren...@ix.netcom.com]

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 RWMutex implementation can be more efficient than the 
general case RWMutex - since you don't need to maintain a list of waiting 
writers. Usually though you would use a specialized data structure designed 
for single writer - multiple reader which can be lock-free for both reading 
and writing.
On Sunday, February 5, 2023 at 12:42:29 AM UTC-6 ba...@iitbombay.org wrote:

> You can implement your own multiple-reader-single-writer-lock using what 
> Go gives you.
> For example: 
> https://eli.thegreenplace.net/2019/implementing-reader-writer-locks/
>
> > On Jan 30, 2023, at 4:42 PM, Robert Engels  wrote:
> > 
> > Yes but only for a single reader - any concurrent reader is going to 
> park/deschedule. 
> > 
> > There’s a reason RW locks exist - and I think it is pretty common - but 
> agree to disagree :)
> > 
> >> On Jan 30, 2023, at 6:23 PM, Ian Lance Taylor  wrote:
> >> 
> >> On Mon, Jan 30, 2023 at 1:00 PM Robert Engels  
> wrote:
> >>> 
> >>> Pure readers do not need any mutex on the fast path. It is an atomic 
> CAS - which is faster than a mutex as it allows concurrent readers. On the 
> slow path - fairness with a waiting or active writer - it degenerates in 
> performance to a simple mutex.
> >>> 
> >>> The issue with a mutex is that you need to acquire it whether reading 
> or writing - this is slow…. (at least compared to an atomic cas)
> >> 
> >> The fast path of a mutex is also an atomic CAS.
> >> 
> >> Ian
> >> 
> > On Jan 30, 2023, at 2:24 PM, Ian Lance Taylor  
> wrote:
>  
>  On Mon, Jan 30, 2023 at 11:26 AM Robert Engels  
> wrote:
> > 
> > I don’t think that is true. A RW lock is always better when the 
> reader activity is far greater than the writer - simply because in a good 
> implementation the read lock can be acquired without blocking/scheduling 
> activity.
>  
>  The best read lock implementation is not going to be better than the
>  best plain mutex implementation. And with current technology any
>  implementation is going to require atomic memory operations which
>  require coordinating cache lines between CPUs. If your reader
>  activity is so large that you get significant contention on a plain
>  mutex (recalling that we are assuming the case where the operations
>  under the read lock are quick) then you are also going to get
>  significant contention on a read lock. The effect is that the read
>  lock isn't going to be faster anyhow in practice, and your program
>  should probably be using a different approach.
>  
>  Ian
>  
> >>> On Jan 30, 2023, at 12:49 PM, Ian Lance Taylor  
> wrote:
> >> 
> >> On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina
> >>  wrote:
> >>> 
> >>> From times to times I write a scraper or some other tool that 
> would authenticate to a service and then use the auth result to do stuff 
> concurrently. But when auth expires, I need to synchronize all my 
> goroutines and have a single one do the re-auth process, check the status, 
> etc. and then arrange for all goroutines to go back to work using the new 
> auth result.
> >>> 
> >>> To generalize the problem: multiple goroutines read a cached value 
> that expires at some point. When it does, they all should block and some 
> I/O operation has to be performed by a single goroutine to renew the cached 
> value, then unblock all other goroutines and have them use the new value.
> >>> 
> >>> I solved this in the past in a number of ways: having a single 
> goroutine that handles the cache by asking it for the value through a 
> channel, using sync.Cond (which btw every time I decide to use I need to 
> carefully re-read its docs and do lots of tests because I never get it 
> right at first). But what I came to do lately is to implement an upgradable 
> lock and have every goroutine do:
> >> 
> >> 
> >> We have historically rejected this kind of adjustable lock. There is
> >> some previous discussion at https://go.dev/issue/4026,
> >> https://go.dev/issue/23513, https://go.dev/issue/38891,
> >> https://go.dev/issue/44049.
> >> 
> >> For a cache where checking that the cached value is valid (not 
> stale)
> >> and fetching the cached value is quick, then in general you will be
> >> better off using a plain Mutex rather than RWMutex. RWMutex is more
> >> complicated and therefore slower. It's only useful to use an RWMutex
> >> when the read case is both contested and relatively slow. If the 
> read
> >> case is fast then the simpler Mutex will tend to be faster. And then
> >> you don't have to worry about upgrading the lock.
> >> 
> 

[go-nuts] Re: Upgradable RLock

[Juliusz Chroboczek]

>> 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 read lock, then an RWMutex
> can be faster.  They key there is that there are always multiple
> goroutines waiting for the lock.

Could you please explain that?  You previously implied that the
required atomic operation is going to make the difference between the
two kinds of mutex irrelevant, why does the argument not apply here?

Thanks,

-- Juliusz

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87tu00b8b3.fsf%40pirx.irif.fr.