[PD] Changing Send/Receive Names After Instantiation

[Christof Ressi]

I've already linked to this GitHub discussion, see below ;-)

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