This caused a pretty bad and subtle bug in the asynchttpserver.
As far as I can understand, the fact that the returned future was
being completed first meant that the underlying async procedure
could continue running and thus clean() the FutureVar
and request new data. The control then went back and the
FutureVar was completed again causing an error.
Implement ConsoleOutputFormatter that is backward compatible
with the previous implementation.
Implement JUnitOutputFormatter which can be added externally.
* Fix kqueue.nim and ansi_c.nim to support dragonfly.
* Fix ioselectors.nim, threads.nim to support dragonfly.
* Fix deprecated dealloc call in tioselectors.nim.
* Fix tfsmonitor.nim test to run only on Linux.
* Fix osproc.nim return wrong exit codes.
* Fix getAppFilename() for dragonfly.
* Fix proper exit code handling.
* Fix 2 problems. First, 0 is a valid fd on Unix (easily gotten if user first
closes all fds and then starts using memfiles). Use -1 instead for an invalid
fd. Second, it is best practice to conserve open fds on Unix and file handles
on Windows. These handles are not needed unless the user wants to remap the
memory with ``mapMem`` (or a hypothetical future ``proc resize``). Adding a
new bool param ``allowRemap=false`` to ``memfiles.open`` solves this cleanly
in a "mostly" backward compatible way. This is only "mostly" because the
default ``false`` case does not keep unneeded resources allocated, but that
most sensible default means that any ``mapMem`` callers need to fix all their
open calls to have allowRemap=true, as this PR also does for tmemfiles2.nim.
* Include backwards compatibility note.
Public coroutine API returns a safe reference to specific running coroutine. Fixes bug where multiple coroutines executing same procedure would identify as same coroutine.
Greatly optimizes `alive()` (and as a result of that `wait()`) calls.
Coroutine struct is allocated together with stack as memory unmanaged by GC.
