The stack was not aligned as expected for `buddy_allocator_init` when
`-o:speed` was enabled, making this a test failure that only appeared
with optimizations enabled.
The data is now aligned specifically, as it should be.
This test is designed to ensure that a call to send will always
correctly report whether the value was transmitted. If recv wins, a
close call should not be able to intercept the send thread.
This commit makes send behave the same as recv: that the call will
return false if the channel is closed while a thread is waiting on the
blocking operation.
Prior logic would have send return true even if the channel was actually
closed rather than read from.
Docs adjusted to make this clear.
Tests added to lock in this behaviour.
This test ensures that contending threads racing to try_send against a
single blocking read will result in exactly one winner without any
senders blocking.
This changes the semantics of try_send to be consistently non-blocking.
That is, if the buffered is full OR there are no readers it returns
false.
The previous behaviour was such that it would block in the latter case
of no reader, and it would wait for a reader. That is problematic
because it produces inconsistent behaviour between buffered and
unbuffered channels which is astonishing and adds complexity to the
caller.
To illustrate the problem with the old behaviour, consider the
try_select operation: if a send-channel happens to be unbuffered the
try_select (which wants to never block) can now block, that unbuffered
send channel is selected (at random) and there is no reader on the other
side. Thus we have unpredictable blocking behaviour, which breaks the
guarantee that try_select never blocks.
If you want a blocking send you can just call "send" (the blocking
variant).
In addition, there is some reader/writer math done inside
can_{send,recv} such that they only report true if there is sufficient
reader/writer capacity. If there is contention we need to ensure that
each reader is paired to exactly one writer.
Consider try_send: if there is a single reader we can send. If there is
a single reader and a single writer, then we cannot send, as that reader
will be paired with the existing writer. Therefore can_send is only true
if there are more readers than writers at the time of check.
NOTE: The original tests don't need to use wait-looping with thread.yield()
or heuristic sleep. Instead we can just use blocking channel operations
rather than non-blocking operations.
These tests will race access to __global_context_for_test, which can
cause the test suite to flake. Even though only a single test actually
references the variable, the logic in try_select consumes it.
This test harness ensures consistent non-blocking semantics and
validates that we have solved the toctou condition.
The __global_context_for_test is a bit of a hack to fuse together the
test supplied proc and the executing logic in packaage chan.
`core:math/big` has been verified against Python's big integer implementation long enough.
Turn it into a regular regression test using the `core:testing` framework, testing against
a generated corpus of test vectors.
In `.Multiline` mode:
- `^` is now defined to assert the start of the string or that a "\n" or
"\r" rune was parsed on last VM dispatch.
- `$` is now defined to consume a newline sequence of "\n", "\r", or
"\r\n" or to assert the end of the string.
This implementation doesn't allow for out-of-band allocations to be passed through, as it's not designed to
track those. Nor is it able to signal those allocations then need to be freed on the backing allocator,
as opposed to regular allocations handled for you when you `destroy` the TLSF instance.
So if we're asked for more than we're configured to grow by, we can fail with an OOM error early, without adding a new pool.
New features:
- If TLSF can't service an allocation made on it, and it's initialized with `new_pool_size` > 0, it will ask the backing allocator for additional memory.
- `estimate_pool_size` can tell you what size your initial (and `new_pool_size`) ought to be if you want to make `count` allocations of `size` and `alignment`, or in its other form, how much backing memory is needed for `count` allocations of `type` and its corresponding size and alignment.
