<div dir="ltr">I guess this is a parallel discussion, right? <div><br></div><div><a href="https://github.com/pure-data/pure-data/pull/604">https://github.com/pure-data/pure-data/pull/604</a><br></div><div><br></div><div>we've been discussing how to add an inlet to [receive] so it behaves like [iem_receive]</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 25 de mar. de 2020 às 18:50, Christof Ressi <<a href="mailto:info@christofressi.com">info@christofressi.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Haha, what I wanted to say is that if you're worried about the danger of <br>
using [iem_receive], then dynamically destroying [r] is not a solution <br>
because it is just as dangerous because the destructor of [r] will <br>
unbind the symbol.<br>
<br>
An easy way to avoid this problem on the user side is to always use a <br>
clock for the message that is going to unbind the symbol. E.g. the <br>
following is always safe:<br>
<br>
... -> [del 0] -> [set foo( -> [iem_receive]<br>
<br>
The reason is that [del 0] breaks the message passing chain and executes <br>
the messages downstream at the beginning of the next scheduler tick. <br>
Same thing for dynamically deleting objects.<br>
<br>
Don't worry too much. If you've been using [iem_receive] and dynamically <br>
deleted objects and didn't experience a crash, it probably means you're <br>
using it in more or less safe ways. It's just something to keep in mind <br>
for your next patch :-)<br>
<br>
Christof<br>
<br>
<br>
On 25.03.2020 22:16, oliver wrote:<br>
> Christof Ressi wrote:<br>
>> Check out the following discussion on GitHub: <br>
>> <a href="https://github.com/pure-data/pure-data/pull/604" rel="noreferrer" target="_blank">https://github.com/pure-data/pure-data/pull/604</a><br>
>><br>
>> TL;DR: if you unbind a symbol from a receiver while sending to the <br>
>> symbol, Pd can crash because you modify the bind list while iterating <br>
>> over it.<br>
>><br>
>> Personally, I've been using [iem_receive] in some projects and didn't <br>
>> run into problems, but only because I avoid the case described above. <br>
><br>
> Thanks Christof for the explanation !<br>
><br>
> @IOhannes: i think this should be noted in the helpfile.<br>
><br>
><br>
>> Dynamically destroying objects is even more dangerous ;-)<br>
><br>
> Bummer ... another thing i do quite often ;-)<br>
><br>
> Since i am not a programmer: how would i decode that twinkle emoji in <br>
> your sentence ?<br>
><br>
> does it mean:<br>
><br>
> a.) be happy that you survived so far, because you're really on mined <br>
> territory here ...<br>
><br>
> b.) i know it's not encouraged, but as long as you don't tell anybody ...<br>
><br>
><br>
><br>
> sorry ... getting a little anxious these days ...   ;-)<br>
><br>
> best<br>
><br>
> oliver<br>
><br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <br>
> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>