2025-08-29 16:13:03 -04:00
|
|
|
* Check through all managed objects and properly refcount them
|
|
|
|
|
using shared_ptr.
|
2025-09-10 18:17:15 -04:00
|
|
|
* Ensure that we comb through the current code and enforce the distinction
|
|
|
|
|
between user errors and program exceptions.
|
2025-10-04 10:42:39 -04:00
|
|
|
* Investigate using UMONITOR/UMWAIT for spinlocks to reduce busy-waiting
|
2025-10-02 20:19:17 -04:00
|
|
|
stress/power consumption. Look for a parallel on ARM.
|
2025-10-04 10:42:39 -04:00
|
|
|
* Investigate WFE/SEV to reduce busy-waiting in spinlocks on ARM.
|
2025-10-04 11:16:04 -04:00
|
|
|
* The input arg `requiredLocks` to LockSet::LockSet() should be
|
|
|
|
|
a ref and not by-value. Propagate this upward into
|
|
|
|
|
SerializedAsyncContin and into all derived classes'
|
|
|
|
|
constructors.
|
2025-10-24 01:11:19 -04:00
|
|
|
* In classes like udpCommandDemuxer and possibly other such background tasks,
|
|
|
|
|
use a spinlock to ensure that the stop() function doesn't deallocate the
|
|
|
|
|
data to be used by the daemon task while the daemon task is executing.
|
2025-10-24 16:03:03 -04:00
|
|
|
* Alternatively we could re-emqueue the message;
|
|
|
|
|
* Alternatively, if select/poll don't consume the read-data-rdy flag,
|
|
|
|
|
we can just return and let the next timer invocation run instead.
|
|
|
|
|
* Alternatively, we can use an xchg'd flag between the udp listener
|
|
|
|
|
and the timed enforcer.
|
2025-10-25 13:17:57 -04:00
|
|
|
* In livoxProto1/device.cpp, migrate the registerUdpCommandHandler() calls
|
|
|
|
|
from using the inProgress collection to the per-device collections.
|
|
|
|
|
* In cases where we use boost deadline_timers and pass in an async
|
|
|
|
|
contin as context preservation across the delay, but they aren't
|
|
|
|
|
part of a branch pattern, we may still need to call cancel() on them
|
|
|
|
|
after they expire just in case boost doesn't clean up the internal
|
|
|
|
|
callable that we passed it. Or else we'll have circular sh_ptr
|
|
|
|
|
references in our continuations.
|