Clarify concurrency of deactivate method

It would appear the spec does not forbid the deactivate method from being called concurrently with the process method. This could lead to memory safety issues if the plugin tries to deallocate resources in its deactivate method while the process method is still using those resources.

So either:
A. In the deactivate method's docs, clarify that resources should NOT be cleaned up in this method.
or
B. Require that the process and deactivate methods not be called concurrently.

certainly seems to me that deactivate should be [main_thread && active && !processing] implying you should call stop processing before decativate if you ever called processing.

lemme ask around though to see if that would get support.

You can't call them concurrently because deactivate would make the plugin not active which would break process() requirements.

Maybe you want to read #516 as well.

right so you cant call deactivate when processing is happening. But that means deactivate is !processing.

the only way to get to !processing is call stop processing. So I think your comment in #516 matches the spec today but not its intent also.

there's nothing in the spec which would stop you from calling processing and while it is being called, call deactivate. This pattern is legal

  AUDIO             MAIN
     |               |
  processing()       |
    .           deactivate()
    .                |
  proc returns()     |
    |                |

So either we need an entire new state 'processing is not being outstanding' (which is unimplementable without a main thread spin lock and an atomic, and is needed nowhere else in the spec) or to change the spec is what most of us concluded, which is deactivate is !processing.

Also from a plugin perspective if deactivate might be called while process is running the plugin has to lock process against the main thread if deactivate frees any resources

I think the contract has to say they do not overlap. The way to do that is to stop processing!

This pattern is legal

  AUDIO             MAIN
     |               |
  processing()       |
    .           deactivate()
    .                |
  proc returns()     |
    |                |

No this pattern isn't legal.

Why not

Like where in the spec does it say that

By the way I agree it is not legal. Deactivste is !processing. But the spec doesn’t say that now

Thinking it is valid is equivalent to think that you can delete an object used by another thread.

No one is arguing that is good
But why doesn’t the spec make it explicit
The transition I described violates nothing in the spec
That’s bad

So if I write that as a host I will point to the spec and say “allowed”. Using the text of the spec show I’m wrong

That’s the question

Or we can modify the spec to say !processing. Or introduce a new spec concept of not-in-process and use it here and only here

But if you think it’s wrong and everyone else does let’s figure out why the spec is missing something

I would argue it violates the active requirement of process, since the plugin isn't active for the full duration of the process call.

It lead to confusion and to keep things simple and logical as possible, it should be defined that the audio thread must have completed stop_processing() in the audio thread before calling deactivate() in the main thread.

This is also logical, because every start gets a stop, every init gets a terminate. It is just a lack of documentation IMHO.
Nobody wants people to get creative and try to save some cycles.

Also (of course) process() must have been completed before calling stop_processing().

Is active false at the end of deactivate or the start? That’s where your statement leads ed. And you’ll end up with active must be true at the end of method x and processing toggles false at the start of method x

Questions like this is why I also agree with timo. !processing is a way cleaner spec for deactivate

Timo said on discord that activate makes active true when it returns, and that deactivate makes active false when it enters. Or, well, I came to the conclusion that this'd be a non-issue if that was the case, and Timo agreed that it's the only realistic interpretation.

Yeah

But process requires active until it completes

So “active” means “is true for the entire call” except for deactivate where it means “true at outset false immediately thereafter” and a host needs to lock its pressing thread somehow and a plugin needs to not assume stop processing is called

So we can add all that to the doc

Or add !processing to deactivate

I don’t think we should do neither and I personally think it makes sense to do the second and require a plugin to get a stop message before deactivate

a host needs to lock its processing thread

or just transfer ownership of the processor to a different thread that doesn't do processing (e.g. the main thread) before deactivating the plugin.

Yeah you could do it with an atomic and a main thread spin as well all sorts of options

Oh also we should indicate that deactivate doesn’t just transition to !active but also transitions to !processing if we don’t require !p for deactivate I guess

Seems a lot clumsier. What’s the argument for not calling stop processing before deactivate other than “spec is currently ambiguous”?

Clarify activate/deactivate and start/stop processing

Navigation Menu

Repository navigation

Clarify concurrency of deactivate method #515

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Clarify concurrency of deactivate method #515

Description

Activity

baconpaul commented on Aug 18, 2026

abique commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

abique commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

abique commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

edwloef commented on Aug 27, 2026

defiantnerd commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

edwloef commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

edwloef commented on Aug 27, 2026

baconpaul commented on Aug 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions