Forums > Dev

How do I stop schedule_delay?

July 28, 2009 | 11:39 pm

Hi all,

Maybe I missed it in the documentation, but I was wondering how to stop a callback from executing once it’s been scheduled by schedule_delay().

I have an object that calls schedule_delay(), but if I delete my object from the patcher before the delay time has elapsed, it still performs the callback even though my object is gone. If I’m lucky, I get a freeobject: bad object message in the Max window, if I’m less lucky, Max crashes. Should I be doing something in my free() method?

I’d rather not use a clock just because I don’t want to manage a queue of data…

Thanks in advance,
JM


July 29, 2009 | 3:51 pm

Sorry — you’ll have to use a clock.

Cheers


August 3, 2009 | 9:05 pm

Really?! So that function (schedule_delay() and variants) should only be called with a delay of 0 to ensure that Max won’t crash if the object is deleted before the delay time is up? That seems pretty lame…

JM


August 3, 2009 | 11:05 pm
John MacCallum wrote on Wed, 29 July 2009 11:39
I have an object that calls schedule_delay(), but if I delete my object from the patcher before the delay time has elapsed, it still performs the callback even though my object is gone. If I’m lucky, I get a freeobject: bad object message in the Max window, if I’m less lucky, Max crashes. Should I be doing something in my free() method?

You should be checking for the validity of the object passed back to your callback function (via !NOGOOD(x) or such).

Your object may be gone, but your callback function is still valid and will try to execute – it’s not a member of your t_object.


August 3, 2009 | 11:43 pm

If you use a clock, you’ll free it in your object’s free method, so the already scheduled event won’t happen. delay2 from the SDK demonstrates that.


November 1, 2011 | 12:10 pm

Hi guys.

I’m running into the exact opposite problem: I am calling schedule_delay expecting the callback to be performed even if the calling object is freed, and this doesn’t happen. I guess some sort of "security" has been added into a recent version of the API, but I’m finding it really inconvenient…

Even worse than that: if I bang the object twice, and delete it from the patcher before the callback has been performed, I get a "bad object" in the Max window.

To see the issue, change plussz like this:

void plussz_bang(t_plussz *x)
{
	schedule_delay(x, (method) plussz_dobang, 3000, NULL, 0, NULL);
}

void plussz_dobang(t_plussz *x, t_symbol *s, short ac, t_atom *av)
{
	post("dobang: x = %p", x);
}

Is there any way (maybe an alternate function call) to override this behavior?

I’m under OSX, MMJ 5.1.9, SDK 5.1.7 (I’d prefer not to switch to the Max6 SDK yet)

Thanks
aa


November 1, 2011 | 3:35 pm

There are many reasons you should not use schedule_delay() and should always prefer clock_delay(). One of these is that with schedule_delay() you have no control or ownership.

It’s difficult to tell what you are trying to do, but it should be possible for you to create a "nobox" class for which you create an instance and then use that object with clock_delay(). You can create this nobox instance at any time (e.g. in your main() function) and then not free it until Max quits (using a quittask).

Cheers,
Tim


November 2, 2011 | 8:29 am

I see… ok, I have done some clock acrobatics, and it looks like I’ve got what I needed.

Thank you
aa


Viewing 8 posts - 1 through 8 (of 8 total)