-
I would like to use the equivalent of the Linux select() statement, which I prefer over the poll() multiplexed i/o in part because of the timeout value being specified in microseconds, whereas poll() is in milliseconds. So I would prefer the higher precision in timing so I can use the timeout to yield but have high precision towards timing based events. Looking through the source code for zsock_select(), it appears that underneath the covers it actually uses zsock_poll() in the source file sockets_select.c, and as a result, it simply converts the microsecond precision timeval into milliseconds. Do I have this understanding correct in terms of zsock_select actual implementation? Is they any other form of single thread multiplexed i/o based on BSD sockets that might provide higher timer fidelity? Assuming my observation is correct, does anyone have an opinion on why the poll() implementation is considered superior? Here is the relevant code from this source file.
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 12 replies
-
Indeed, select() is using poll() atm. After looking the code, I think it is trivial to change the code to internally use higher precision in poll implementation and just convert to desired precision in select/poll when calling the internal poll implementation. Patches are welcome if you want to go this route. |
Beta Was this translation helpful? Give feedback.
-
I have a fix proposal at #36220 |
Beta Was this translation helpful? Give feedback.
-
In my review comment #36220 (review) , I explain why select() in Zephyr was implemented the way it is, and those were deliberate requirements. Theoretical higher resolution of select() is just that - theoretical benefit, which in practice would only lead to confusion - 1 microsecond passed to select() would likely get rounded up to much higher value (if not on the order of milliseconds, then tenth of milliseconds). As I mention there, if not thinking in terms of synthetic resolutions, but in algorithmic complexity/conversion overheads, the only way forward is to implement epoll(), but that takes timeout in milliseconds either. There're a lot of materials on the topic by just googling "select vs poll", here's random google hit: https://devarea.com/linux-io-multiplexing-select-vs-poll-vs-epoll/ and quote:
|
Beta Was this translation helpful? Give feedback.
-
Thanks Jukka, for spending the time and getting this into the main branch. It would not have happened without you handling the logistics and leveraging both you knowledge of the Zephyr network stack as well as the primary contributors to the project necessary for reviewing the effort and getting it into the main repo. |
Beta Was this translation helpful? Give feedback.
Indeed, select() is using poll() atm. After looking the code, I think it is trivial to change the code to internally use higher precision in poll implementation and just convert to desired precision in select/poll when calling the internal poll implementation. Patches are welcome if you want to go this route.
We also support
SO_RCVTIMEO
that allows application to define the receive timeout in microsecond resolution.