Hi Ico and list - On Tue, Jun 19, 2012 at 10:20:07PM -0400, Ivica Ico Bukvic wrote:
-----Original Message----- From: Miller Puckette [mailto:msp@ucsd.edu] Sent: Tuesday, June 19, 2012 5:11 PM To: Ivica Ico Bukvic Cc: 'Claude Heiland-Allen'; Hans-Christoph Steiner; pd-list@iem.at Subject: Re: [PD] variable receive objects?
I don't think your patch works in every case (I think you simply have to
check
every e->e_who inside functions like bindlist_bang() before dereferencing them since someone could clear one of them while inside a previous one).
Thanks for the update, Miller. Is there a way you could give me an example patch that would fail this way? I ask this simply because I am unable to imagine one you describe here. Namely, even if a parent's send has been changed by the child-of-a-child object this way, this change would only make specific instance point to null object but its pointer would be still valid until its entire sub-tree has been navigated, and only after its entire sub-tree has been navigated would it be actually dereferencing stuff and fixing the pointers accordingly before the next incoming wave of calls.
I don't have an example handy but here's a stack pseudo-trace:
... bindlist_bang() pd_bang(first item in bindlist) ... toggle_receive() <--- zeros out second item in bindlist
then when pd_bang returns, bindlist_bang proceeds to dereference second item in bindlist and... not bang but more like 'boom'.
Also, there are declarations after functional lines, e.g.,
- change_bindlist_via_graph = 1; t_bindelem *e;
which is not standard C - something I frequently have to clean up in
people's
patches :)
You mean declaration of a global variable needs to be placed at the top of the source file? Sure, that is an easy fix. It's been placed here in proximity to make the patch more legible.
It's an automatic variable whose declaration should be at the beginning of a block. Otherwise Visual C++ seems to get offended (and I don't find out until I crank up my stupid windows machine :)
I think something like what you proposed could work; there would still be
a
performance hit which I'd probably want to measure before committing to doing this... since after all we're just talking about a wierd and
obnoxious
'feature' in IEMGUIs that I would simply take out if I could :)
I am not so sure there is a performance hit since in both cases dereferencing happens in exactly the same way, except in this one the referencing is delayed and in the interim structs destined to be dereferenced are made to point to null and then skipped if a subsequent call trips over a null-pointing struct before it has been dereferenced. As such its performance impact should be minimal.
Main performance hit would be that every time anyone traverses a bindlist (many send/receive messages, perhaps most) there's all that extra code in bindlist_bang(), etc. needed to make the extra tests (possible zero receiver and possible cleanup needed afterward).
cheers M