-
Notifications
You must be signed in to change notification settings - Fork 320
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.
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
iio_buffer_refill() returns "bad file descriptor" error after timeout #981
Comments
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. |
it's with network backend. |
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 <[email protected]>
Could you try with the |
that seems to be fixed now |
Good! Now I just need to make sure I didn't break anything :D |
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
@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 ? |
It will (hopefully) be fixed there as soon as the master branch is merged back into the dev branch. |
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 callingiio_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 ifiio_buffer_cancel
is thread safe or not. (I did not experience a crash so far).The text was updated successfully, but these errors were encountered: