FelipeMdeO commented on code in PR #19596:
URL: https://github.com/apache/nuttx/pull/19596#discussion_r3699500514
##########
drivers/sensors/sensor.c:
##########
@@ -1177,12 +1248,40 @@ static int sensor_poll(FAR struct file *filep,
fds->priv = filep;
if (lower->ops->fetch)
{
- /* Always return POLLIN for fetch only sensor: the data is read
- * from the device on demand by sensor_read(), so there is never
- * anything to wait for.
+ /* A fetch() only sensor is read from the device on demand, so it
+ * is always ready unless this subscriber asked for a rate, in
+ * which case it becomes ready once per interval and
+ * sensor_fetch_worker() is what wakes the poll.
+ */
+
+#ifdef CONFIG_SCHED_LPWORK
+ if (user->state.interval == UINT32_MAX)
+ {
+ eventset |= POLLIN;
+ }
+ else
+ {
+ uint64_t now = sensor_get_timestamp();
+ uint64_t elapsed = now - user->fetched;
+
+ if (elapsed >= user->state.interval)
+ {
+ user->fetched = now;
+ eventset |= POLLIN;
+ }
+ else
+ {
+ work_queue(LPWORK, &user->work, sensor_fetch_worker, user,
Review Comment:
Hello Xiang, I can't find a better solution.
Following my approach, the default use case is to use read or poll without
an interval — in this case, no thread or work item. When the work item is used,
it fires at the same cadence the caller wants to wake at anyway, so it's not
extra cost, just moved from a userspace sleep to a kernel timer.
Another point is that orb_set_interval() already means "poll() gets ready
about this often" for a pushing sensor. Without this, it silently means nothing
for a fetch()-only one — a trap for anyone writing sensor-agnostic code against
uORB.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
