Those buffers are in one go routine so no conflict. Buffers passed between
go routines are allocated from the pool by the sender and freed back to the
pool by the receiver. I did initially have some bad corruption going on due
to not copying data in certain places where partial data went to more than
one go routine and having references into slices which were then recycled.
After fixing those issues I was left with some strangeness in the data
which I just can't find the cause of. I've checked the return from all the
copy statements and the expected amount of data is always copied.

I should probably explain that this is a software radio implementation and
I have random clicking and distortion in the output. The hardware can run
up to 8 receivers and if I enable more than one which creates parallel
paths in the program for the signal processing the corruption gets worse to
the point of no discernible signals. The hardware is not at fault because I
have other software that works correctly. I'm also pretty sure my
application code is correct as I've implemented this before in other
languages. There is a lot going on in this app and clearly I've messed up
somewhere but I'm running out of debug approaches. I'm using the latest go
beta and assuming the language is solid enough not to be causing this.

Any suggested approaches very welcome.

On Friday, November 1, 2013 8:37:29 AM UTC, bobco...@gmail.com wrote:


I think I must be misunderstanding something.

I have 2 buffers to double buffer data.
They are created with zero length and capacity to hold the data that will
be written to them.
buf_1 = make ([]float64, 0, n)
buf_2 = make ([]float64, 0, n)

I then select which buffer to use by assigning it to a local variable.
var curr_buffer []float64 = buf_1
var next_buffer []float64 = buf_2

Now as I understand it I have a copy of the reference but the same
underlying data.

If I now append to say buf_1.
curr_buffer = append(curr_buffer, data...)

After the append the length of curr_buffer is len(data) but the length of
buf_1 is zero.
As the capacity was sufficient to hold the data I didn't expect a

I also tried this without the local variables by splitting the function
and passing the references - same result.

I then tried pointers to references which worked, but that was expected.

Can someone enlighten me on the mechanism going on here please.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedNov 1, '13 at 12:29p
activeNov 3, '13 at 5:22p



site design / logo © 2022 Grokbase