GitOrigin-RevId: ac60fd3cf4a24023184376687da28373d14b781a
This mirrors the robotpy files for the following projects:
- apriltag
- datalog
- hal
- ntcore
- romiVendordep
- wpilibc
- wpimath
- xrpVendordep
This excludes cscore and the halsim wrappers for at this time.
NOTE: This does not hook these projects up to the build system, just simply mirrors the files. The building will take place in a follow up PR to make it easier to review the changes necessary to build.
I upgraded all plugins I could see except org.ysb33r.doxygen. 2.0 made
breaking changes, and I couldn't figure out how to migrate.
Most of the changes are for suppressing new linter purification rites.
Currently the major DataLog backend API (reading and writing) is split between wpiutil and glass. In the interest of allowing code that wants to use these APIs to not need to link to glass and declutter wpiutil, all of those APIs are moved to a new library named "datalog".
Signed-off-by: Jade Turner <spacey-sooty@proton.me>
Co-authored-by: Jade Turner <spacey-sooty@proton.me>
Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
The changes in #7189 caused an ambiguity between multi-subscribers and
normal subscribers, because the handle type no longer is sent to the network.
Multi-subscribers now go to the network with negative UIDs, normal
subscribers are positive UIDs. UID 0 is never used.
Each client has an incoming queue of ClientMessage.
In the read callback:
- Parse and process only ping messages and a limited number of messages;
anything else will get put into the queue and not processed
- If we queued some messages, we tell the network we stopped reading; this will
result in back-pressure if we are reading too slowly. We also start an idle
handle to process the queued messages.
In the idle handle callback:
- For each client, process just a few pending messages. This is performed in
round-robin fashion across all clients with pending messages
- When a client's queue becomes empty, we re-enable the network read
- When all client queues are empty, we stop the idle handle (so we don't spin)
For local client processing, we use round-robin processing for most cases (including FlushLocal),
but still do batch processing of all local changes for explicit network Flush() calls.
The stream can close (e.g. due to an error) while in the middle of writing. The close callback would immediately destroy the connection object, resulting in the writing code having a use-after-free. Fix this by deferring the deletion to the loop main using a single-shot timer.
