This allows a server to write a characteristic and automatically
notify/indicate all subscribed clients.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
After a client does a successful `await char.notified()`, then before the
next call to `notified()` a notification arrives, then they call
`notified()` twice before the _next_ notification, the second call will
return None rather than waiting.
This applies the same fix as in 5a86aa5866
which solved a similar problem for server-side `char.written()`. Using
a deque is slightly overkill here, but it's consistent with the server
side, and also makes it very easy to support having a notification queue
in the future.
Also makes the client characteristic properly flags/properties-aware (i.e.
explicitly fail operations that aren't supported).
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This fixes a bug where an incoming write before `written` is awaited causes
`written` to return None. It also introduces a mechanism for a server to
"capture" all incoming written values (instead of only having access to the
most recent value).
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Any custom handlers will be passed a LogRecord instance which has members
and a dict with "levelname", "message" and "name", to be used for creating
a log message. The handler list is a global singleton so that sub-logging
objects all use the same set of (root) handlers.
The name of the root handler is also changed from None to "root", to match
CPython.
Signed-off-by: Damien George <damien@micropython.org>
Instead of using single priority queue for all tasks, split into using
"run queue", which represents tasks not waiting until specific time,
which should be run on every (well, next) loop iteration, and wait queue,
still a priority queue. Run queue is a simple FIFO, implemented by
ucollections.deque, recently introduced in pfalcon/micropython. Thus,
there's minimal storage overhead and intrinsic scheduling fairness.
Generally, run queue should hold both a callback/coro and its arguments,
but as we don't feed any send args into coros still, it's optimized to
hold just 1 items for coros, while 2 for callbacks.
Introducing run queue will also allow to get rid of tie-breaking counter
in utimeq implementation, which was introduced to enforce fair scheduling.
It's no longer needed, as all tasks which should be run at given time
are batch-removed from wait queue and batch-inserted into run queue. So,
they may be executed not in the order scheduled (due to non-stable order
of heap), but the whole batch will be executed "atomically", and any new
schedulings from will be processed no earlier than next loop iteration.
Jim Mussared