On Sunday, 31 August 2025 at 12:44:33 UTC, Brother Bill wrote:
On Sunday, 31 August 2025 at 01:27:57 UTC, Steven Schveighoffer
wrote:
Why would your second iteration make a difference? Purely by
chance! In fact, on my machine, it does not exit in either
case.
Welcome to the wonderful world of race conditions and
multithreading!
So this was just 'bad' luck with 'race conditions'.
It is not a failure of the D compiler.
Yes, the (bad) luck seemed to suggest your changes were causing a
different behavior, whereas actually it was just hitting the race
condition differently. I've spent many hours on issues such as
this. You think some behavior is happening because you changed x,
but really it's due to y, and the change just happens to be
triggering a difference in y, or some coincidence is happening.
Race conditions are really hard to figure out. Couple that with
memory safety issues, you are in big trouble.
FWIW, given that D supports Message Passing Concurrency, is
Data Sharing Concurrency just there for D completeness, for
those that want to live close to the iron.
Correct. You are not absolved of the responsibility of ensuring
you don't use pointers after free.
If you want this extra check, you need to mark your function as
`@safe`. This will prevent, among other things, taking the
address of a local variable as you have done here.
It would seem that Message Passing Concurrency should be our
first, second and third choice for concurrency.
Yes, aside from the issue with lifetime here, you technically are
not properly synchronizing access to your boolean. But in this
case, it should properly work. Other cases may not be correct
without more synchronization (mutexes or using atomics).
`std.concurrency` is meant to make all these control flow systems
easy to avoid races for, even in `@safe` code. Sending the
boolean instead of keeping a pointer to a shared boolean can
alleviate a lot of these problems.
-Steve
