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.