This helps people using the mem.Tracking_Allocator to more easily
pinpoint where they leaked memory in their own code, rather than
having the leaks be reported as if they were in the core library
itself.
Virtually all code (except for user-written custom allocators) should work as normal. Extra features will need to be added to make the current procedures support the `Allocator_Error` return value (akin to #optional_ok)
Also do some cleanup and refactoring of the thread, sync and time APIs.
- remove 'semaphore_release' because 'post' and 'wait' is easier to understand
- change 'semaphore_wait' to '*_wait_for' to match Condition
- pthreads can be given a stack, but doing so requires the user to set up the guard
pages manually. BE WARNED. The alignment requirements of the stack are also
platform-dependant; it may need to be page size aligned on some systems.
Unclear which systems, however. See 'os.get_page_size', and 'mem.make_aligned'.
HOWEVER: I was unable to get custom stacks with guard pages working reliably,
so while you can do it, the API does not support it.
- add 'os.get_page_size', 'mem.make_aligned', and 'mem.new_aligned'.
- removed thread return values because windows and linux are not consistent; windows returns 'i32'
and pthreads return 'void*'; besides which, if you really wanted to communicate how the
thread exited, you probably wouldn't do it with the thread's exit code.
- fixed 'thread.is_done' on Windows; it didn't report true immediately after calling 'thread.join'.
- moved time related stuff out of 'core:os' to 'core:time'.
- add 'mem.align_backward'
- fixed default allocator alignment
The heap on Windows, and calloc on Linux, both have no facility to request alignment.
It's a bit of hack, but the heap_allocator now overallocates; `size + alignment` bytes,
and aligns things to at least 2.
It does both of these things to ensure that there is at least two bytes before the payload,
which it uses to store how much padding it needed to insert in order to fulfil the alignment
requested.
- make conditions more sane by matching the Windows behaviour.
The fact that they were signalled now lingers until a thread tries to wait,
causing them to just pass by uninterrupted, without sleeping or locking the
underlying mutex, as it would otherwise need to do.
This means that a thread no longer has to be waiting in order to be signalled, which
avoids timing bugs that causes deadlocks that are hard to debug and fix.
See the comment on the `sync.Condition.flag` field.
- add thread priority: `thread.create(worker_proc, .High)`
