[riot-notifications] [RIOT-OS/RIOT] pkg/semtech-loramac: fix deadlock when sending unconfirmed messages (#11535)
notifications at github.com
Thu May 16 18:45:42 CEST 2019
Thanks for tackling this.
> I tried other solutions, like setting a message queue to the caller thread but I found this was a workaround not really fixing the original issue.
Strictly speaking the TX Done status should be reported by the Confirm primitive and any kind of data reception by Indication (although the pkg seems to call Indication even for ACKs...). I think it would simplify a lot the implementation if we use the messages as signals instead of a synchronization between the caller and MAC.
Also, "Indication right after Confirm" is only valid for class A, so we would need a message queue anyway for class B and class C.
What do you think about:
- Sending a message with the packet to the caller in case of an Indication with data (same principle as GNRC's `_pass_on_pkt`)
- Decide if we send an extra message with TX status. In most cases this is handled internally by the MAC (increment tx_failed counter), but I'm aware most LoRaWAN applications directly interact with the MAC.
This way we could also send other information to the caller (Link Check, etc) and the caller can't block or de-synchronize the MAC layer.
What do you think?
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...
More information about the notifications