|
|
May 28, 2009 at 9:22pm
Length of lists
I’m addressing updates to the Lobjects for version 5, and confronting a question that has been around since ’93. How long a list can I pass out via outlet_list? 256 was the old standard, enforced by the fact that message would crash if you hit it harder than that. Many users seem to need lists longer than that, and I suppose we can all afford the memory.
But how long should they be before it makes more sense to program with jitter?
The zl objects are still 256, I note, even zl len.
|
|
|
May 28, 2009 at 11:10pm
zl’s 1st arg can be an int setting the max length to something other than 256 (this is documented in zl.maxhelp but I didn’t look in there either until ej pointed me in the right direction..)
|
|
|
May 28, 2009 at 11:25pm
Hi Peter,
Since Max 5, zl is limited to 32767 items, but the default maximum list length is still set to 256 for compatibility and efficiency reasons (if the first argument of zl is a number, it sets the maximum atom array length). The way it’s usually done is that there’s still an atom array of 256 items allocated on the stack, and if that’s not enough we allocate memory dynamically. This is done using atom_dynamic_start() and atom_dynamic_end() which are defined in ext_proto.h.
So it gives something like that (forum coding…).
#define STACK_LISTMAX 256
void yourobject_yourmethod(t_yourobject *x, t_symbol *s, long ac, t_atom *av)
{
t_atom temp[STACK_LISTMAX];
t_atom *a;
long i;
a = atom_dynamic_start(temp, STACK_LISTMAX, ac); // this basically returns temp if ac < STACK_LIST (or allocate memory and returns it)
// do something... like add 74...
for (i = 0; i < ac; i++)
atom_setlong(&a[i], atom_getlong(av[i]) + 74);
outlet_list(x->myout, NULL, ac, a);
// release or not depending on if it has been allocated in atom_dynamic_start() or not
atom_dynamic_end(temp, a);
}
Does that make sense?
|
|
|
May 29, 2009 at 11:09am
This may be moot, but well-behaved Max 4 objects wouldn’t crash if they received a list longer than 256. They would just truncate the list.
There may have been misbehaved exceptions, but I’m pretty sure they were exceptions.
The first thing in any of my list-handling methods is to test the argc parameter and make sure it’s not bigger than what I’m able to handle.
I would hope the same holds for Cycling ’74 code.
|
|
|
Jun 5, 2009 at 5:03pm
So, could I write a generic expansion routine that grabs more storage when a long list comes in?
And use atom_dynamic_end to release it when an even bigger list arrives? Does this cause a memory leak, or are you into garbage collection now?
My objects keep three lists most of the time.
4.5 was mostly immune to list related crashes, but I was able to break the message object pretty consistently– not immediately, but if the patch was saved with a huge message it would crash on reopening. A binbuf thing, I think.
pqe
|
|
|
Jun 5, 2009 at 9:50pm
You can simply use atom_dynamic_start() and atom_dynamic_end(). It does take care of the extra memory allocation if the input is bigger than the memory that you allocated on your stack.
|
