Since the semantics are different w.r.t. path separators, the alternative suggested in the deprecation message is not valid. At least until the comparison/toString semantics of PathSegment have a profound definition, it will be kept around to avoid unneeded interruptions when upgrading to 0.8.x.
- Copying LocalManualEvent now works correctly, using reference counting
- ManualEvent correctly pins the reference to the thread-local waiter until it has finished emitting it
- ThreadLocalWaiter uses a doubly-linked list to manage task waiters (more efficient deletion, FIFO trigger order)
- Fixed a bug in ThreadLocalWaiter.emit() where the head element of the iterated list might already have stopped waiting, resulting in an invocation of a dangling TaskWaiter pointer
This will have to be adjusted to use a circular list with the possibility to insert a pivot element, so that consumption of waiters is safe in all cases (see the comment at 1265).
The approach for now is to keep overloads that receive system delegates and are also marked system in turn. This breaks safety promises in some places within the library, but is an acceptable first step that keeps other possible directions open.
The previous design, while intended as an improvement over the one-size-fits all Path struct of vibe-d:core, turned out to produce lots of bugs during the transition, because of missing Path.type checks.
The new design uses a cleaner approach, where the static type of a path value encodes the path format. An explicit cast is necessary to convert between different path types. The internet path type also performs proper validation and percent encoding, so that InetPath.toString() always produces a valid URI path.
The deadlock happened because a function that waits for a worker task to finish was passed to the log functions. Evaluated lazily, it got called while the logger's mutex was locked, meaning that any log call from within that thread would cause a deadlock.
This change also has another, possibly important, implication - arguments are evaluated only once instead of possibly multiple times if multiple loggers are registered. This could very well make a lot of existing (wrong) code more robust (e.g. logInfo("%s", i++)).
