[PD] variable receive objects?

[Ivica Ico Bukvic]

On 05/18/2012 07:08 AM, Claude Heiland-Allen wrote:
> On 14/05/12 19:43, Jonathan Wilkes wrote:
>>
>> How do I manifest the bug?
>
> See attached.  Uses iem_r, though it should make no difference which 
> settable-receive you use.
>
> WARNING: clicking the "boom" message makes Pd segfault :WARNING
>
> To understand this you need to know that pd stores a receiver in the 
> symbol table.  When there is only one receiver, it's just a pointer to 
> the object, but when there's more than one there's a proxy object that 
> contains a list.  When you change a receiver it can end up deleting 
> the proxy object if the receiver count for a symbol drops from 2 to 1. 
> Deleting an object while code is executing in its context -> boom.
>
>
> Claude
What if the send/receive property was handled via clock_delay(0); ? If I 
understand the underlying mechanism correctly, this would put the 
changing of the receive at the end of the current working queue and/or 
the beginning of the next one. Either way, the process that had to take 
place would've either already taken place or would happen after the 
change was done. Again, all this is assuming I understand how the 
clock_delay(0); works. This would generate a bit of an out-of-sequence 
delay (in terms of order of execution), but if that solves the crash, it 
would be probably a trade-off worth tolerating. Perhaps adding a second 
outlet that signals that the receive has been reset (e.g. via bang) 
would allow to sync the rest of the operations... All that said, this is 
awful close to being a hack rather than a solution.

-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound&  Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT Integrative Performance Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net