libusb.free() race about gousb HOT 7 CLOSED

Thanks, I think that's a good point. The xferDoneMap entry is overwritten by the alloc that happens to return the same pointer that was already freed and not yet removed. And I think it might happen more frequently than I initially thought, if only because the lock might hold the goroutine at that exact point. So the probability goes up as you start churning more and more transfers.

I'll send a fix. Did you encounter this problem in practice? The basic Read/Write is very inefficient because it allocates a new transfer for every single operation and there's no way to queue them up other than parallelizing around your Reads. We now have a streaming interface for reads, which allocates a ring buffer of transfers and keeps multiple transfers in flight all the time. It reduces the overhead of memory allocation and interval between subsequent transfers. If you haven't tried it yet, I'd encourage you to give it a go. We don't have a Write stream implementation yet, but it could be added too.

from gousb.

Thanks for the info!

I did indeed run into this problem in practice when multiple goroutines were used for optimizing performance. I was unaware of the streaming API, and once the write stream implementation is completed, this does indeed sound like a preferable option.

from gousb.

Just gave the read stream interface a shot and indeed works great, without worrying about packets reordering, etc :)

from gousb.

May I ask what USB device you're using for continuous writing? I have multiple devices from which I can read in streams, like a USB camera, but I don't have good use cases for writes that I could try out myself.

from gousb.

Fixed by #15.

from gousb.

For write test cases, you could use Android's AOA (https://source.android.com/devices/accessories/protocol), and there are some small examples on github if you don't feel like writing your own Android app for that.

from gousb.

#19 implements a write stream.

from gousb.