libiio 1.0: cannot create new buffer after cancel operation

[catkira]

When I abort a dequeue operation with iio_buffer_cancel and then try to create a new buffer with iio_device_create_buffer I get

ERROR: Unable to create buffer: Device or resource busy (16)

for about 3 seconds. After that iio_device_create_buffer works again without doing anything else. Is this a bug? It would be nice if I could create a new buffer immediately after cancel for my application.
I am using a network context. Latest libiio dev branch is running on host and device.

[catkira]

This is the output of iiod when I run it on the device in a terminal

New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
New client connected from 192.168.137.1
Client exited
Client exited
Client exited
Client exited
Client exited
Client exited
Client exited
Client exited
Client exited
Client exited
New client connected from 192.168.137.1
Client exited
Client exited

for every unsuccessful iio_device_create_buffer I get a New client connected from 192.168.137.1 on the terminal. Then suddenly I get a lot of Client exited all at once.

[catkira]

Ah I figured out that the Device or resource busy (16) errors comes after a cancel operation for the duration of the timeout I set with iio_context_set_timeout. So I guess that there is probably an active timeout timer running that is not properly reset when iio_buffer_cancel happens.

[catkira]

Even if I don't do iio_buffer_cancel and just let the iio_block_dequeue timeout, I have to wait another timeout duration before I can create a new buffer.

[catkira]

The problem seems to appear only when I run libiio 1.0 on the network client side. local libiio 1.0 and client libiio 0.24 does not show this problem.

[pcercuei]

Noted, thanks for testing Libiio v1.0 btw.

[pcercuei]

@catkira It should be fixed in the PR #1000

[pcercuei]

Closing as this issue was fixed.