IPB

Welcome Guest ( Log In | Register )

> foobar2000 Development Forum Rules

This forum is for developer discussions only. If you have a problem / bug report / idea / feature request that isn't related to foobar2000 SDK, post it in an appropiate forum instead - tech support questions go to support forum, everything else goes to general forum.
All non-developer posts on this forum will be removed. Continued abuse of this forum will result in admin actions (warnings, account suspension).

 
Reply to this topicStart new topic
playlist_manager / main_thread_callback
jonpb
post Apr 17 2013, 04:07
Post #1





Group: Members
Posts: 122
Joined: 21-August 06
Member No.: 34268



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
Go to the top of the page
+Quote Post
Zao
post Apr 17 2013, 04:34
Post #2





Group: Members (Donating)
Posts: 899
Joined: 25-September 03
From: Umeň, Sweden
Member No.: 9001



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
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.

This post has been edited by Zao: Apr 17 2013, 04:36


--------------------
Zao shang yong zao nong zao rang zao ren zao.
To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.
Go to the top of the page
+Quote Post
jonpb
post Apr 17 2013, 05:18
Post #3





Group: Members
Posts: 122
Joined: 21-August 06
Member No.: 34268



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.

This post has been edited by jonpb: Apr 17 2013, 06:06
Go to the top of the page
+Quote Post
Zao
post Apr 17 2013, 17:35
Post #4





Group: Members (Donating)
Posts: 899
Joined: 25-September 03
From: Umeň, Sweden
Member No.: 9001



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.


--------------------
Zao shang yong zao nong zao rang zao ren zao.
To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 2nd August 2014 - 09:12