Re: RFC: async I/O facility: "zpoll" API

Andy Ross

Joseph, Jithu wrote:
I think this implies that callback is made from (a new) zpoll
thread,(which will get built into the system) and not from the
context which invokes zpoll_signal().
Right. It's made from the system work queue, the same thread that
handles {nano,k}_work_submit entries. The signal call is typically
going to be made from interrupt context, which is a really poor place
to be issuing arbitrary user callbacks.

If the user app is interested only in a one async callback event ,
For e.g if the user app after making the uart_write_async_cb()
(which internally calls zpoll_event_init_cb()) call, should it still
call zpoll() ( if so will it return immediately - even when the
event has not occurred - so that the main thread can continue) or
can it continue remaining instructions without calling zpoll() ?
If you really are interested in only one event, you probably want to
be using the existing synchronous API. :)

But yes: zpoll() will block. You can specify a timeout to ensure you
come back (or TICKS_NONE -- I just now realized I need to have support
for that, even though in this case it's just a noop), or include a
semaphore as your own "wake up" signal that you can control from
another thread.

If you want to poll for completion for some reason, you can check
zpoll_get_result() from any context.


Join to automatically receive all group messages.