[riot-notifications] [RIOT-OS/RIOT] sock: initial definitions for asynchronous event handling (#11723)

Kaspar Schleiser notifications at github.com
Wed Jun 19 15:21:27 CEST 2019

Nice move forward!

Some thoughts (only brief look):

- if we introduce a generic ```sock_t``` first, that all other sock types (udp, tcp, ip, ...) inherit from, the API gets a lot smaller, and the async handling part can be written once, for all of them. And IMO, as now we're starting to get shared funtionality, this would actually make sense to introduce.
I'm envisioning only a couple of ops, like read(), write(), close(), status(), setup_async_event() .

- the event type needs to be OR'ed.

If I see correctly, there's one "ctx" per sock, and thus one event object. If now there are multiple events (CAN_READ | CLOSED), the second that arrives overwrites the first. The event should be used as bitfield, and it should be set in a way that even if the event is already queued, a subsequent bit that gets set can still be read.

- Do you think we need to go all generic with the callback method?

I think we might get away with just ifdef'ing support for the different event methods, without resorting to custom types.
Like, only ```#ifdef MODULE_SOCK_ASYNC_EVENT```, the necessary fields are added to "sock_x_t", and the helper functions are included.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190619/6849b626/attachment.html>

More information about the notifications mailing list