gnrc_netif: Add support for internal event loop#9326
gnrc_netif: Add support for internal event loop#9326jnohlgard wants to merge 6 commits intoRIOT-OS:masterfrom
Conversation
miri64
left a comment
There was a problem hiding this comment.
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
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.
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_eventspseudo 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