>
By all means, no! Quite the opposite. I noticed, that for just a single call of 
async my queue backend received multiple insert operations, especially when 
used on the default pool.
 From that I concluded, that the thread_data* pushed to the Pending_Queueing 
queue do not all originate from user-code calls of async (and the like). That 
means there are thread_data elements that hold _coroutines with parameters that 
I have no control over. Is that correct?
How could I differentiate between thread_data elements created by user-level 
async calls and thread_data elements created by the system?
<

Aha. now I understand what you mean. Sadly the tasks generated internally by 
the system are not distinguishable from user tasks. The way to do it, would be 
to create a custom executor that handled async/then etc (I'm doing that now and 
it's a huge PITA). Then you will only get the tasks that are posted to your own 
executor and not see the ones generated by the system.

A custom pool, with your scheduler, should not see system generated tasks, you 
could leave just one thread for the default pool and use the rest in yours.

We do not yet support it, but the plan is to allow oversubscription - so that 
you could have 9 threads on an 8 core machine, a single one in the default 
pool, then 8 in yours. Then there'd be a bit of overhead with the OS swapping 
those threads out, but it ought to work  well enough. I have not tried doing 
this yet, but it is planned.


>
For all intents and purposes the extra parameter can be handled like it was 
just another parameter to be passed to the action. If need be, I can package 
all actions to have an additional first parameter, which is not passed on to 
the packaged action. My problem is: Can I access the parameters of the function 
represented by a thread_data element via that thread_data element?
<

Not really. I tried that before I started on a custom executor.


re:Priorities and early ray termination. I will ponder this some more.


JB
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Reply via email to