Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

iio_buffer_refill() returns "bad file descriptor" error after timeout #981

Closed
catkira opened this issue Jun 8, 2023 · 7 comments · Fixed by #996
Closed

iio_buffer_refill() returns "bad file descriptor" error after timeout #981

catkira opened this issue Jun 8, 2023 · 7 comments · Fixed by #996

Comments

@catkira
Copy link
Contributor

catkira commented Jun 8, 2023

I am using a separat thread to read a iio buffer with iio_buffer_refill. When there is not data in the buffer for a duration larger than the timeout, I get a "timeout" return value which is ok. However when I try calling iio_buffer_refill after that I get a "bad file descriptor" error and I need to close to buffer to get out of this state.
Is this the intended behaviour or a bug?

My current workaround is to make the timeout super long, so that the timeout is practically never reached. But in order to join the buffer-read thread, I need to call iio_buffer_cancel from the outside thread now to make the buffer-read thread join. I don't know if iio_buffer_cancel is thread safe or not. (I did not experience a crash so far).
@pcercuei
Copy link
Contributor

This is with the local backend, or the network backend?

We didn't really design the timeout feature as the way you are trying to use it, more as a way to detect that something is seriously wrong - and in that case it is expected that the application would just destroy the context.

I'll have a look to see if it's possible to tweak it.

@catkira
Copy link
Contributor Author

catkira commented Jun 21, 2023

it's with network backend.
To recover it is not necessary to destroy the context, destroying the buffer is enough. But it would be nice if it is not necessary to destroy the buffer after a timeout.
Using a super long timeout and then calling iio_buffer_cancel to get out of the read thread is ok with libiio 0.24, but it does not work with libiio 1.0 frontend because of this issue #985

pcercuei added a commit that referenced this issue Jun 22, 2023
@pcercuei
IIOD: Better handle errors of iio_buffer_{refill,push}
1323fe5 
Pass the error code to the connected clients, instead of disconnecting
them.

This means that for a very slow device, a connected client will simply
get a -ETIMEDOUT error when a configured timeout expires, and will still
be able to communicate with the server.

Fixes: #981.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
@pcercuei
Copy link
Contributor

Could you try with the pcercuei/iiod-handle-kernel-timeout branch?

@catkira
Copy link
Contributor Author

catkira commented Jun 22, 2023

that seems to be fixed now

@pcercuei
Copy link
Contributor

Good! Now I just need to make sure I didn't break anything :D

@pcercuei pcercuei mentioned this issue Jun 22, 2023
Merged
pcercuei added a commit that referenced this issue Jun 22, 2023
@pcercuei
IIOD: Better handle errors of iio_buffer_{refill,push}
e1da15b 
Pass the error code to the connected clients, instead of disconnecting
them.

This means that for a very slow device, a connected client will simply
get a -ETIMEDOUT error when a configured timeout expires, and will still
be able to communicate with the server.

Fixes: #981.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
pcercuei added a commit that referenced this issue Jun 23, 2023
@pcercuei
IIOD: Better handle errors of iio_buffer_{refill,push}
9209fe0 
Pass the error code to the connected clients, instead of disconnecting
them.

This means that for a very slow device, a connected client will simply
get a -ETIMEDOUT error when a configured timeout expires, and will still
be able to communicate with the server.

Fixes: #981.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
pcercuei added a commit that referenced this issue Jun 23, 2023
@pcercuei
IIOD: Better handle errors of iio_buffer_{refill,push}
ad199c6 
Pass the error code to the connected clients, instead of disconnecting
them.

This means that for a very slow device, a connected client will simply
get a -ETIMEDOUT error when a configured timeout expires, and will still
be able to communicate with the server.

Fixes: #981.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
@catkira
Copy link
Contributor Author

catkira commented Jun 24, 2023

@pcercuei This problem is now solved when I use libiio 0.x on front (ad936x device) and backend (network PC) (switching the frontend to this new PR solved it). But it still persists when I use libiio 1.0 on fronend and libiio 0.24 on backend, the fix does not help here. Should I make a separate issue for that or can You port this fix to libiio 1.0 ?

@pcercuei
Copy link
Contributor

It will (hopefully) be fixed there as soon as the master branch is merged back into the dev branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

IIOD: Better handle errors of iio_buffer_{refill,push} analogdevicesinc/libiio
2 participants
@pcercuei @catkira