-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnrc_netif: Add support for internal event loop #9326
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main conceptual question I have, is why you are under the impression that messages are ordered and synchronous and events are none of those.
@miri64 Perhaps a bad choice of words. The idea is to make sure that ISRs will always be executed before any queued external requests (send/recv/get/set). In the future, it will also be useful to be able to insert other implementation specific events which can be handled first just like the ISR event, for example turning on the radio when it is time for a wake period in a duty cycling MAC, or handling timeouts and other exceptional events. |
There's also the concept that there should only ever be a need for exactly one queued ISR event in the event loop, since the radio driver should probably take care of everything that has to be done in one go and the duplicated ISR events will just be no-ops, whereas there may be several queued send events with different data. |
1dfdad0
to
db4c8ce
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@miri64 addressed comments, rebased
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gebart do you have something prepared to test this?
d5f76b3
to
9980882
Compare
@miri64 rebased, refactored to address comment. |
@miri64 The ContikiMAC implementation requires this event loop to be able to schedule waking periods and retransmissions properly, using the message queue would let applications interfere with the timing of wake periods and retransmissions, or we would have to perform tasks from within interrupt context to preempt the normal flow of the thread. |
I think apart from the ifdef issue pointed out above, I think I'm alright with this, but I need to see when the diff is better trackable. |
@miri64 new version pushed. The block you mentioned was rewritten into a separate function, also the behaviour was slightly altered to let the thread check for events between each successive IPC message, even when more than one msg have been queued. This should make the behaviour more predictable and robust. Events are always processed as soon as possible, and any events which occur as a side effect of one of the processed messages will be handled before the next message is processed. |
Ok, finally before I give my ACK, some doc on the new behavior would be nice (also mention that events take precedence over messages and ISR events are handled as a event)... I don't know exactly this should go though :-/. Maybe in a newly introduced details section in |
ef37898
to
7e873e3
Compare
2338476
to
4462fd5
Compare
Enabled by the gnrc_netif_events pseudo module. Using an internal event loop within the gnrc_netif thread eliminates the risk of lost interrupts and lets ISR events always be handled before any send/receive requests from other threads are processed. The events in the event loop is also a potential hook for MAC layers and other link layer modules which may need to inject and process events before any external IPC messages are handled.
44c1fc2
to
39a29bb
Compare
If this PR is rebased (and squashed) and #9326 (comment) is addressed optionally, I think we can finally merge this (sorry dropped off my radar again >.<) |
@gebart ping? |
Ping @gebart? |
/* dispatch netdev, MAC and gnrc_netapi messages */ | ||
DEBUG("gnrc_netif: message %u\n", (unsigned)msg.type); | ||
switch (msg.type) { | ||
case NETDEV_MSG_TYPE_EVENT: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this case can be #ifndef
'd
@gebart this is indeed an interesting feature! Thanks Since there's no activity for some time, mind if I take it? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Contribution description
Enabled by the
gnrc_netif_events
pseudo module. Using an internal event loop eliminates the risk of lost interrupts and lets ISR events always be handled before any send/receive requests from other threads are processed.The events in the event loop is also a potential hook for MAC layers and other link layer modules which may need a way to inject and process events before any external IPC messages are handled.
Issues/PRs references