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

Andy Ross

Benjamin Walsh wrote:
- This should be a native kernel feature. It should probably be called
k_poll rather than zpoll.
Will do. I'm calling it zpoll only because the semantics aren't
exactly equivalent to unix poll and I didn't want to address the
confusion. But that naming is probably better.

Shouldn't we have a pointer to a workqueue, so that the work could
be scheduled on another workqueue than the system one if desired ?
That seems reasonable. Though currently I'm envisioning the work
queue as purely a convenience feature above the lower level API. It's
there to issue the callbacks and that's it. Someone who wants finer
control over what happens when should be making the poll call directly

Shouldn't this be a union since one zpoll event instance should be
for one object ?


Where is zpoll_call defined ? Isn't that simply a k_tid_t ?
One zpoll_event struct goes with one request, and a bundle of them
with (zero or) one waiting thread blocked under zpoll(). That's what
the zpoll_call struct is, it's a private record stored on the stack of
the pended zpoll call. Basically it's the arguments to the function
and a list link, so the other threads can enumerate the pended threads
and events to figure out which ones are complete and who to wake up.

void _zpoll_sem_signal(struct k_sem *sem);
Do we need this ? Shouldn't this be the job of k_sem_give() to handle
waking up a thread from its polling ?
It is. This is the utility code that does that. It's hooked out of
k_sem_give(), checks one bit (which I stole from the count/limit) to
see if there's a blocked zpoll thread, then hands control to this
thing to wake it up. It's not strictly part of the API and got left
here because it's in the same header block I pasted in. :)


Join to automatically receive all group messages.