ivmarkov

> > If Cortex-M0/M0+ is always single-core (is it?) > > No, see RP2040 Ah so you mean for rp2040 they use a spinlock+disable-all-interrupts software impl? If yes, then this...

...and if spinlocking+disable-all-interrupts is fine as a strategy, then the `critical-section` impl of `portable-atomic` is good enough of a workaround for multicore.

> > No, see RP2040 > > Beaten me in 5 secs lol > > > Ah so you mean for rp2040 they use a spinlock+disable-all-interrupts software impl? If yes,...

> A gentle ping here [@ivmarkov](https://github.com/ivmarkov) [@MabezDev](https://github.com/MabezDev) > > On the IDF part, I believe IDF already provides some kind of critical section: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos_idf.html#api-changes which can be used directly Even...

> > Is it safe to call interrupt disable instruction from user code in xtensa-*-esp-idf? For example, RISC-V and Arm usually restrict the use of such instructions in user mode....

> > > Is it safe to call interrupt disable instruction from user code in xtensa-*-esp-idf? For example, RISC-V and Arm usually restrict the use of such instructions in user...

> > it seems to correctly implement atomic-CAS-with-possible-spurious-failures **without** spinlocking the other CPU? > > Yes but I think the Rust Devs will argue that if one thread calls this...

> cc @ivmarkov Any idea why this would be happening? No idea. Will try to reproduce once I'm back.

Couldn't get to there yet. Sorry about that! Very likely will try to do something related to async-io in the next couple of days.

@npmenard Thank you for the detailed analysis! I can reproduce the issue (though I haven't connected with GDB to examine the address), and I confirm that the dummy `listener.is_listening();` is...