[PD-dev] long lasting operations

[Thomas Grill]

Hi all,
the other day i had to compare Max and PD again, and it seems that one of
PDs core weaknesses is the fact that all messaged operations are happening
synchronously, that is, with no respect whether they'll fit into the
real-time schedule.
A good example is soundfiler, where reading and writing of large files is
done in one piece which inevitable leads to audio cracks.
In Max for these kind of operations there exists a low-priority message
queue (using so-called qelems) which can be used to retrigger an operation
that is executed in chunks. These qelems can also be dropped if they are
occuring more than once in a queue, or postponed if audio timing needs it.
This can't really be done equally in PD by using clock_delay as an
alternative.
Since PD has a global thread lock now, the other (probably more comfortable)
way would be to use threading for longer-lasting operations, and i'd really
like to adapt soundfiler and other objects accordingly.
The problem with any asynchronous array operation is that there has to be a
mechanism to avoid concurrent changing of table sizes by two separate
objects (e.g. when one soundfiler is reading data into the array, another
one must not resize the same array)... consequently there has to be some
kind of "array lock" or even a queue of operations scheduled for execution,
because i don't think that operations should just fail... or are there any
other ideas how to do it?

best greetings,
Thomas