AlexHarker

object_method_typed ((t_object *)target, gensym("sizeinsamps"), 1, temp_atom, temp_atom + 1);

The function in question runs in a max thread (not the msp thread). My question is - will the resize operation ever be deferred to a later time, or can I be confident that at the end of the above code it will have either succeeded or failed?

I ideally I need to resize the buffer in a way that:

2 - means that I know that the buffer has either resizing, or that the resize has failed

I want to avoid the possibility that the resize will happen at some later time to when I actually request it, as I need to immediately work on the data after the resize. At the moment I am probably doing everything in the low priority thread anyway - I can live with this being a necessity if that is the case.

It seems to work at the moment, just looking for advice of this - spinning until something is done is also an option I don't mind. The operation is not time critical, but the determinacy and order of events is paramount.

t_atom temp_atom[2];
atom_setlong(temp_atom, new_size);
object_method_typed ((t_object *)target, gensym("sizeinsamps"), 1, temp_atom, temp_atom + 1);

2 - means that I know that the buffer has either resizing, or that the resize has failed 

buffer-resize-programmatically-questions

i case you haven't seen it, i had a similar question on the form some time ago.

https://cycling74.com/forums/resizing-buffer-notify

tim proposed to set up a notify method and check for a "buffer_modified" message.

hi alex,
i case you haven't seen it, i had a similar question on the form some time ago.
https://cycling74.com/forums/resizing-buffer-notify

To add to what Volker contributed, I will say that 'sizeinsamps' does defer internally if it is not called on the main thread.

Thanks guys - that gives me some further pointers to work with.

I don't want the situation to become asynchronous if poss.

I'm assuming from your post Tim that if I call it from the main thread then it should be synchronous? That for me would be the best solution (simply to make sure I'm in a the main low priority thread).

@alex, yes, in the current implementation it should be synchronous if called from the main thread. There is no guarantee that it will be this way in perpetuity, but there are also no immediate plans to change it either.

@alex, yes, in the current implementation it should be synchronous if called from the main thread.  There is no guarantee that it will be this way in perpetuity, but there are also no immediate plans to change it either.

Hi Tim, I stumbled upon this more than 10 years later. From my tests, it seems that 'sizeinsamps' is still deferred to the main thread.

But is there any way to change the size of the buffer no matter the thread we are in, and keep it synchronous? Is there a non-deferred version of the 'sizeinsamps' setting I could also use in the scheduler, for instance?

Hi Tim, I stumbled upon this more than 10 years later. From my tests, it seems that 'sizeinsamps' is still deferred to the main thread.
But is there any way to change the size of the buffer no matter the thread we are in, and keep it synchronous?  Is there a non-deferred version of the 'sizeinsamps' setting I could also use in the scheduler, for instance?
Thanks,
Daniele


highly unlikely, how could max tell the OS to make sure to dedicate 30 gb RAM to "foo" within the next 1ms?

The 1ms timing is not an issue, honestly, the issue is synchronicity: I need to be sure that I can rely on the resizing happening before everything I do next. Whether it takes 1ms or 1year! And I need to do it in a way that users are allowed to work in a separate thread or in the high priority thread.

I would call a sysmem_resizeptr() on the samples manually but I guess that's not really the way to go ;-)

The 1ms timing is not an issue, honestly, the issue is synchronicity: I need to be sure that I can rely on the resizing happening before everything I do next. Whether it takes 1ms or 1year! And I need to do it in a way that users are allowed to work in a separate thread or in the high priority thread.
I would call a sysmem_resizeptr() on the samples manually but I guess that's not really the way to go ;-)


sorry i misinterpreted "deferred", so i was wondering why the order could be an issue in the main thread.

@daniele I don't think there's a way around this. What we ended up doing in flucoma was enabling people to use the high priority thread if they had preallocated space in their output buffers, whilst still offering automatic resizing from the main thread. This seems to work ok for those people who *really* want to use the high priority thread for buffer based work, although it does violate the principle of Least Surprise if people aren't already intimate with how Max does threading. I did think about trying to be 'clever' and defer jobs that required a resize, but decided it would end up being more confusing and error-prone,

I'm at peace with this insofar as the high priority thread deserves treating with almost the same careful reverence as the audio thread in terms of avoiding waits and indeterminate timing: indeed, it could be that this stuff is actually running on the audio thread if Scheduler in Audio Interrupt is turned on.

I'm at peace with this insofar as the high priority thread deserves treating with almost  the same careful reverence as the audio thread in terms of avoiding waits and indeterminate timing: indeed, it could be that this stuff is actually running on the audio thread if Scheduler in Audio Interrupt is turned on.

Thanks a lot Owen, I understand. Incidentally, I was stumbling on this because I was "borrowing" (...trying to copy...) your FluCoMa @blocking mechanism, which seems to me extremely well designed. However, the fact that patches operate differently according to the thread they are in (no resizing in one object may mean that everything is messed up later on) is a real downside. I'm not sure I want to go down this road.

I assume the same is true for when your blocking attribute is set to a dedicated thread: you cannot resize a buffer in the thread you create, correct?

All of this still makes me think that a non-deferred buffer resize would have lots usages (including being used in one's own threads): to be employed with all the caution (and all the due respect the scheduler thread deserves, as you say ;-) - but nonetheless necessary if one needs consistency across different scenarios.

I assume the same is true for when your  blocking attribute is set to a dedicated thread: you cannot resize a buffer in the thread you create, correct? 

buffer~ resize programmatically questions