This is set to the FPGA clock by HAL_Initialize. Note this change means
that libuv loops should not be started until after HAL_Initialize is called (on the Rio).
Non-Rio functionality is unchanged.
Static destruction order is not well defined, so it was possible for outs()
or errs() return value to be destroyed even while other code was running,
resulting in a crash. Instead dynamically allocate the static so the
destructor never runs. While this technically leaks, valgrind generally
supresses such leaks as the data is still "reachable" from the static pointer.
This avoids a number of shutdown use-after-free races by controlling the
destruction order. It also is a prerequisite to making the internal
interfaces mockable for unit testing.
The static condition variable was getting destroyed before the DS thread exited,
resulting in a deadlock on program exit when the DS thread tried to notify it.
This change moves the condition variable into the DS thread to avoid the race.
The next line adds a null terminator, but it's cleaner to just do a
std::memcpy() since the code already assumes a null terminator exists in
the source string.
- Build both debug and release binaries
- Append "d" to debug libraries in the style of opencv
- Split shared and static classifiers
- Add raspbian support
Originally, the command was restarted every time the scheduler was
executed if the button was pressed. #1340 changed this behavior in a
breaking manner.
Other handles can only be used within the loop itself, but Async is intended
to be used from another thread. This introduces the possibility of a race
condition between the loop being destroyed and the Async being destroyed.
Change Async to keep a weak reference to a loop and check it before performing
libuv operations.
This allows the called function to pass along the promise to another
asynchronous callback.
To avoid memory allocations, add a home-rolled, simplified, non-allocating
version of std::promise and std::future as wpi::promise and wpi::future.
Since https://github.com/wpilibsuite/allwpilib/issues/786 has been
closed as not a legitimate concern, there is now no reason to use
IterativeRobot over TimedRobot. It's a drop-in replacement that's
strictly an improvement in terms of execution jitter.
To migrate, one simply has to replace the IterativeRobot subclass in
their robot code with TimedRobot.
