Hi,
On 11 Dec 2016, at 11:55, Christopher Collins wrote:
On Sun, Dec 11, 2016 at 11:13:47AM -0800, Sterling Hughes wrote:
Hi,
As a part of developing the sensor interface, I want to register a
“listener” on the event queue:
listener.sl_sensor_type = type;
listener.sl_func = sensor_shell_read_listener;
listener.sl_arg = &ctx;
rc = sensor_register_listener(sensor, &listener);
if (rc != 0) {
goto err;
}
And then I want to essentially “wait” until I’ve read ’n’
entries, and block in my task:
/* Block until we've read 'n' samples. */
while (ctx.num_entries < nsamples) {
os_eventq_run(sensor_mgr_evq_get());
os_time_delay(1);
}
The sensor_shell_read_listener() function updates “num_entries”,
and
when I’ve read the desired number of samples, the loop finishes.
Just calling os_time_delay() or os_eventq_run() in and of themselves
is
not sufficient:
- os_eventq_run() will let the current task’s events (default event
queue in this case) run, but won’t process other tasks events (e.g.
shell is run out of a separate task in this case.)
Sorry if I'm being dense here, but there is something I am missing.
Why
won't other tasks run while you block on the sensor event queue? This
should only be an issue if the event queue is never empty, right? Are
you expecting this eventq to be receiving events faster than you can
deqeueue them or something?
I think my problem was actually that I’m executing the sensor_mgr_evq
in the shell task context, and those are not the same. So, shell events
(console_writes()) were not going out.
I think it would be simpler to understand if the default event queue was
per-task.
i.e. take a scenario where you have:
main task -> runs default event queue
sub-task: runs shell
right now you need to configure the shell to use a different event
queue, that you create in the sub-task and set for that package. if you
don’t, bad things happen silently, because you are calling
eventq_get() on the same event queue (default) from 2 different task
contexts.
I don’t think an event queue per-task would be huge overhead, and I
think it would make the programming model much simpler. Now, whatever
co-operative threads you located within a single task context, would
automatically use the same event queue. As opposed to having to be
cognizant of what thread they are running in, and set the event queue
for that thread, in that scenario.
Sterling