Asynchronous state saving/loading

[Quant1um]

Currently, according to #195, functions like state::load and state::save must be called on the main thread of the operating system, which somewhat limits what hosts can do with respect to loading/saving parameter state on a separate thread to speed up saving/loading large projects.

It would be nice if there was a way to tell the host that the state loading/saving functions are actually thread-safe, or if there was an "async state" extension that has thread-safe load/save functions.

[baconpaul]

Ive wanted something like this also.

I don’t think you would necessarily want thread safe load save, but rather would want an async state extension which had an initiate load / initiate save method on the plugin and a notify conclude load / notify conclude save method on the host which were all main thread and took a shared cookie to inform which load or save was complete. Then the plugin can splin a thread do a request callback and inform type pattern. That’s a bit more idiomatic to the way other async things work in clap

[defiantnerd]

This would also help when losding samples etc, to notify the host when it is ready to playback.

[baconpaul]

Yeah Shortcircuit is the case where I want this indeed

[Quant1um]

I don’t think you would necessarily want thread safe load save, but rather would want an async state extension which had an initiate load / initiate save method on the plugin and a notify conclude load / notify conclude save method on the host which were all main thread and took a shared cookie to inform which load or save was complete. Then the plugin can splin a thread do a request callback and inform type pattern. That’s a bit more idiomatic to the way other async things work in clap

That could work, yea

One downside to this method is that every plugin would have to spin up a thread by itself, while with thread-safe save/load host could use a thread pool or a similar mechanism which could be a bit more performant (though I am not sure that this is a big deal in practice).

[prokopyl]

I've got some different ideas as to how a system like this could work.
I started to make a super long post detailing it, but I think code would be more explicit, so I just opened a PR here #485 😅

[Quant1um]

Hmmm, I was thinking what if we had a common background thread extension like:

// this is similar to `on_main_thread`/`request_callback`
// background-thread is a symbolic thread
// plugins can use any synchronization mechanisms like atomics or spsc queues to send arbitrary task data
// alternatively, `request_background` could take a "cookie" pointer which would be sent to `on_background_thread`, simplifying plugin side implementation by eliminating the need to use queues

typedef struct clap_plugin_background_thread {
    // Called by the host on the background thread in response to a previous call to `request_background`
    // [background-thread]
    void(CLAP_ABI *on_background_thread)(const clap_plugin_t *plugin);
}

typedef struct clap_host_background_thread {
    // Ask the host to call `on_background_thread` on the background thread 
    // [thread-safe]
    void(CLAP_ABI *request_background)(const clap_plugin_t *plugin);
}

And if we had an "async-state" extension as proposed by @baconpaul, the call sequence could be something like:

1. Host calls clap_plugin_async_state::save on the main thread
2. Plugin in response adds task information (context, streams, etc) to a queue for example, and calls clap_host_background_thread::request_background
3. Host calls clap_plugin_background_thread::on_background_thread
4. Plugin takes the task info from the queue and does the saving/writing to stream. For this to work, the stream object must be safe to pass around threads.
5. Plugin calls request_callback after it is finished saving
6. Host calls on_main_thread
7. Plugin calls clap_host_async_state::on_saved

Same call sequence could work for "preset-load" extension as it exists today

[Quant1um]

Now we have background-state-context so this should be possible.