Previously when enum values not defined in the original enum type were
used in serialized objects, FC threw exceptions when it encountered
these values. Now it just serializes unknown values to and from numbers
instead of names.
As an added benefit, the compiler now warns you if a value is defined in
the enum, but not reflected!
Fix fc::thread to set the thread name in the Debugger when the name is set after thread construction.
When terminating a thread, cancel any tasks that have been schedule()d or async()ed but have not yet started executing.
When canceling a task blocked on a fc::mutex, notify the thread to reschedule the task to allow it to clean up the mutex's block list.
Fix a bug in managing the recursive lock count when tasks block on a fc::mutex
Reorder the code that manages the hard links for log files to avoid an exception generated by unlinking a locked file on Windows.
Modify the log file configuration and rotating code to call to_native_ansi_path() and do more paths manipulation in fc::path objects and less in std::strings, in an attempt to improve BitShares/bitshares_toolkit#791
and writes. This was previously unsafe because we almost always passed read/write
buffers to boost that were on the stack. Canceling the task deleted the stack and
therefore the buffer, but couldn't reliably prevent boost from writing to the buffer
if data came in after the cancel. This commit adds variants of the read and write
functions that take a shared_ptr<char> instead of a raw char* as the buffer, and
these variants will ensure the shared_ptr will outlive the boost::asio read/write.
Re-organize read-loop execution to avoid crashes in read_loop on Win32 when ntp object destructs. Call quit on ntp_thread when ntp object destructs to free up thread (eventually we need to make fc::threads call quit in their destructor, but more work is required to make that work properly).
~fc::udp_socket now closes socket on destruction (consider doing this for tcp sockets as well).
- we were canceling tasks that hadn't been canceled, because the canceled flag was left set to true and the next task assigned to the context then became canceled as soon as it yielded
- we were resumeing blocked tasks before they should have resumed, because their blocking_promises list wasn't cleared and they were unblocking because the erroneous promises were fulfilled
As a debugging aid, we also record the cancellation reason whenever a task is canceled, and include that in the canceled_exception (this is only enabled in debug builds)
