Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: playlist_manager / main_thread_callback (Read 2203 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

playlist_manager / main_thread_callback

I just want to make sure I understand this and I'm not missing something.

As far as I can tell, there is no way to call functions in playlist_manager that returns a value, either as an "out" parameter or a return type, from a worker thread. main_thread_callback can be used for functions that do not return a value, but I can't find a mechanism to call functions that return a value and that need to be called on the main thread from a worker thread.

Thanks

playlist_manager / main_thread_callback

Reply #1
When you implement main_thread_callback, add some additional state to the object like a future, or if you lack those, an event and a place where the data needs to be.

Code: [Select]
struct task : main_thread_callback
{
  future<T> value;
  some_state state;
  virtual void on_run()
  {
    value = static_api_t<playlist_manager>->get_somesuch(state.foo, state.bar);
  }
};

{
  service_ptr_t<task> my_task(new service_impl_t<task>());
  my_task.state = ...;
  static_api_t<mtc_whatever>->enqueue(my_task);
  auto T = my_task.value.get();
}


TL;DR -- you can put arbitrary state in your main_thread_callback implementation.
See my generic in_main_thread function for foo_wave_seekbar to see how one may do something similiar.
Stay sane, exile.

playlist_manager / main_thread_callback

Reply #2
Thanks very much for the tip zao, and especially for the source code.

I think your "function object" solution makes perfect sense. As long as the main_thread_callback_manager queues them and processes them in order I think I can use main_thread_callback_manager with your "function object" solution.

Thanks again

PS. multiple edits on this post, hopefully I was talking to myself.

playlist_manager / main_thread_callback

Reply #3
The intent of my example is that you dispatch a task to the main_thread machinery, and then you block, waiting for the result.
If you want to do something asynchronous, you can instead have the main_thread_callback raise some kind of event, or post a callback
back to a similar machinery for your workers.

If you do that, I suggest bundling some uniquely identifying information with the callback, so you can determine what request a delayed response belongs to.
Stay sane, exile.