This pull requests reminds me of a conversation we had a while ago, and my reaction now is pretty much what it was then: http://createdigitalnoise.com/discussion/334/accessing-arrays-in-pd

The upshot is, these changes don't seem quite safe, and I'm not sure what the use case is. I suggest we start with the use case and see how we can address it.

I agree that it's reasonable to require client code to make a defensive copy. Yeah, it's technically slower but I should be fine in most cases and keeps thread issues to a minimum.

Regarding the use of resizeArray and getArrayAsBuffer, @nettoyeurny is certainly correct that they can be misused to the point of causing a segfault. They definitely require programmer care, separately and when used together. The best the can I could offer is to add more detailed documentation on what the constraints are and that they are advanced methods.

My personal use case is reading an audio file outside of Pd and writing the sample data into a table. In the patch I ensure that the table is not being accessed, I resize the table, then get a FloatBuffer representation to the table and begin to fill it while reading the file. This can be done without having to read the entire file into memory first and then copying it into Pd's table. The use of FloatBuffer and ShortBuffer also allow byte arrays to be easily accessed as floats or shorts, without having to do any awkward bitshifting.

Similarly, @nettoyeurny's thoughts are also correct regarding executeSynchronizedRunnable. And again, yes it's advanced, I can offer to add more documentation explaining its use.

My use case is that I have an external which runs in Pd, but also has a Java component which has its own threads, independently of Pd. At some point the Java thread needs to update state in the native external struct, and I need to be able to guarantee that the audio thread (i.e. Pd) isn't in there doing something. Thus, executeSynchronizedRunnable.

@nettoyeurny What's your take on this now that locking is built into the C core? Access to filling arrays directly would solve the problem of missing native file format support in libpd for iOS, etc.

Also, I'd like to see this in the C core.

I agree with Peter regarding the direct buffer access. It's probably best done manually outside of libpd when you really need it. Also, newer capabilities such as integrating double support internally would mean we couldn't guarantee the buffer type you are accessing, at least not trivially for most cases.

However, I think being able to resize an array is definitely useful and ported your implementation to #281.

What about the idea of swapping arrays, so that read/write operations can be done without the lock?

I feel this takes use more into wrapper territory. The base C API should be simple and straight forward. I could see something a little more complicated like this being introduced as an additional helper utility, etc.