flac.Parse funcs are prone to data races

[zachorosz]

Hello! Thanks for the wonderful library!

I'm trying to Parse multiple .flac files concurrently where each file is being parsed by its own goroutine (not multiple goroutines parsing 1 file). Getting some flakey results because readBytes func uses a global buffer and is prone to data races.

Is there any harm not using this global buffer? Could make a slice of size n in the func itself - would allocate it on the stack up until a certain size I think.

This is the commit that introduced this: e03baec (I know it's pretty old :/ )

[mewmew]

Hello! Thanks for the wonderful library!

Hej Zach! Happy to hear you like the library : )

I'm trying to Parse multiple .flac files concurrently where each file is being parsed by its own goroutine (not multiple goroutines parsing 1 file). Getting some flakey results because readBytes func uses a global buffer and is prone to data races.

Is there any harm not using this global buffer? Could make a slice of size n in the func itself - would allocate it on the stack up until a certain size I think.

This is the commit that introduced this: e03baec (I know it's pretty old :/ )

Definitely helpful that you dug up the commit which introduced the race condition. Thanks!

PR #57 should resolve this.

Could you check if #57 is enough to resolve your race conditions?

Cheers,
Robin

[zachorosz]

Thank you @mewmew! Pulled the branch and can confirm it works as expected!

[mewmew]

Thank you @mewmew! Pulled the branch and can confirm it works as expected!

Wonderful. I'll merge PR #57 and tag the v1.0.8 release of the flac library : )