Need to discuss the following design ideas:

Single-threaded vs. multi-threaded worker pool.

Currently SDK is single-threaded worker pool + WinInet thread pool for HTTP requests on Windows. In some service scenarios it is more advantageous to maintain more than one background worker thread.

Single vs. multiple pools for multiple SDK (LogManager) instances

Currently SDK shares one thread pool between many several LogManager instances. In some scenarios it might be best to have independent thread pools for each "channel" (for each LogManager instance).

Ability to track a task by unique TaskId

Rough-in proposed implementation is added in PR #266, but currently it's not used for task cancellation and task look-up. raw task ptr used instead. This is not robust and potentially error-prone in some corner cases, esp. if a new task gets allocated on heap with the same ptr while we idle-waited with sleep on task completion.

Ability to associate a task with its owner LogManager

Currently tasks are not in any way, shape or form are linked back to their parent LogManagers and their deferred task handles. It would be of benefit to consolidate (join, terminate, run to completion or cancel) all outstanding tasks that belong to certain instance of LogManager on that instance shutdown, so that we have no orphan tasks running.