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.
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..)
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?
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.
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
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.