<p>Ad individual sensors, handling will need to be per sensor in some way anyway -- otherwise a single observation on, say. the cheap-to-observe push button will make the eSAUL thread poll expensive bus-wired sensors with no need.</p>
<p>My concern about messages is what's happening when queues overflow. A level-based IPC like process flags will ensure the behavior which saul_gcoap will expect -- intermediate values might be lost, but the last is the latest. In a message approach (as I understand, no matter whether regular msg or msg bus), you might lose the last messages. In the smartwatch example, if its knob sits on a rotary encoder, the moment you start turning it may spit out 4 messages, fill the queue, and not forward the following 5-6 events that indicate its eventual resting position.</p>
<p>In xtimer, we're offering several ways for an event receiver to set itself up -- as a message, as a flag, at a mutex or through a signal. Do we want to pick one of those, or have the same generality? (Neat as it'd be to have abstraction over those, that may not be immediately possible, for the xtimer only fires one event, whereas subscription to an eSAUL change would be in an (intrusively?) linked list of listeners, unless we go with the message bus.)</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/issues/14121#issuecomment-633606905">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABE7WYAWQASDPHKWM4CK62DRTKAN3ANCNFSM4NIOMK5Q">unsubscribe</a>.<img src="https://github.com/notifications/beacon/ABE7WYANNZTJSO6KFDGGK5DRTKAN3A5CNFSM4NIOMK52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEXCBF6I.gif" height="1" width="1" alt="" /></p>
"name": "View Issue"
"description": "View this Issue on GitHub",