Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Am 11.02.2007 um 21:50 schrieb Tim Blechmann:
Well, then how should Pd solve the logical pitfalls in your opinion?
mark the object as deletable, if the messaging is happening, wait for the object to return from the message function, then it can be safely deleted.
exactly, but the object should not process any further messages when the mark is set. I recently encountered the same situation, and by debugging i found that the crash happens while traversing the outlets to see if the message should be sent to other objects. It would be easy to check for such a mark there.
I'm wondering: There are other, less obvious cases of suicide that currently lead to a crash. I encountered this when trying to close the Gem-window by watching for the <Esc> key with [gemkeyname] connected to [0, destroy(--[gemwin]. This also crashes Pd and according to IOhannes for a similar reason. Inserting a [delay] in between this will fix it as well. However here not a single object is deleted. Which object should be "marked" here?
btw, this has been fixed in Gem some time ago (at least it should!) the way it is done, is by entering a "deletable" state, which will be executed asap (but after stack execution), which is basically after a [del 0] (sounds familiar...)
i am not totally happy with this solution because of the following problem: [destroy, create( what should happen here? (well the answer is trivial; but it is not so trivial any more, if we depend on execution order) 2 solutions come to my mind: - since [destroy( is delayed, [create( has to be delayed too; this would lead us to hell... - since the window is still existing when we call [create(, no new window is created (but the destruction is canceled); this is NOT what we have told the interpreter to do; destroying and re-creating a context is NOT the same as not touching it at all.
i think the problem is not a big one, if we consider only the single case of destroying the Gem-window. (this could always be seen as a "special" case)
however, i don't think it is a valid assumption for pd itself. in this case, i would highly prefer an error-message to the console (an "exception") and no destruction at all. (since usually you have more complex settings when doing dynamic patching, e.g. [clear, obj 0 0 inlet, obj 0 100 outlet, connect 0 0 1 0( )
i think i have said this already, the last time this issue came up.
mfg.asd IOhannes