Files
Odin/core
Jack Mordaunt c29168f76f core/sync/chan.try_send: avoid blocking if no reader is available
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.
2025-06-12 17:35:48 -03:00
..
2025-05-04 15:48:26 +10:00
2025-06-09 15:09:04 +02:00
2025-05-08 13:23:22 +01:00
2024-02-08 15:15:16 +00:00
2025-06-06 10:42:34 +02:00
2025-05-26 14:48:45 -04:00
2025-06-12 17:09:33 +02:00
2025-06-08 17:03:43 -07:00