It looks like the channels initialization API might be overwriting the channel data-structures in the shared memory. The __chan_init_with private API (called within chan_snd_init_with and chan_rcv_init_with) currently checks if something has been produced, if so, it doesn't initialize the blockpoints but in other cases, for example, if someone's waiting on the blockpoint, it is not handled, instead the channel is reinitialized, perhaps causing the issue I have seen.
The issue in chan_evt.toml: chan_hi initializes both channels and does a send and a receive in the rendezvous, and it looks like chan_lo only does channel initialization after this point in chan_hi, and making the chan_send from chan_lo never to wakeup the chan_hi that was previously blocked on chan_recv.
Workaround used: The way I dealt with it, is after the chan_hi does its initialization it sleeps for 10ms and so does chan_lo. This way, they're both initialized by the time either of them do send or recv from those channels.
It looks like the channels initialization API might be overwriting the channel data-structures in the shared memory. The
__chan_init_withprivate API (called withinchan_snd_init_withandchan_rcv_init_with) currently checks if something has been produced, if so, it doesn't initialize the blockpoints but in other cases, for example, if someone's waiting on the blockpoint, it is not handled, instead the channel is reinitialized, perhaps causing the issue I have seen.The issue in
chan_evt.toml:chan_hiinitializes both channels and does a send and a receive in the rendezvous, and it looks likechan_loonly does channel initialization after this point inchan_hi, and making thechan_sendfromchan_lonever to wakeup thechan_hithat was previously blocked onchan_recv.Workaround used: The way I dealt with it, is after the
chan_hidoes its initialization it sleeps for 10ms and so doeschan_lo. This way, they're both initialized by the time either of them do send or recv from those channels.