simbergm has quit [Write error: Connection reset by peer]
jaafar has quit [Ping timeout: 268 seconds]
hkaiser has joined #ste||ar
simbergm has joined #ste||ar
<simbergm>
heller: yt?
<heller>
simbergm: Hey
<heller>
What's up?
<simbergm>
execution_agent... I'd like some help :)
<heller>
Sure
<simbergm>
I'm trying to create a thread_data module to sit on top of coroutines
<simbergm>
thread_data_stackful has an execution_agent member, which in turn depends on the scheduler for the do_resume member function
<simbergm>
ideally I'd like for thread_data not to depend on the scheduler and execution_agent
<simbergm>
two options that I see so far
<simbergm>
1. don't have the execution_agent member in thread_data_stackful
<heller>
Why shouldn't it depend on it?
<simbergm>
big module
<simbergm>
but if it's unavoidable we'll go for that of course
<simbergm>
your answer will probably determine if it ends up as a big module or not
<heller>
Hmm, I'm not seeing why it should not depend on it
<simbergm>
does the execution_agent member in thread_data_stackful have to have the same lifetime as the thread_data_stackful itself?
<heller>
No, it the agent needs to exceed the lifetime of it
<simbergm>
needs to exceed? it has the exact same lifetime now
<simbergm>
but you can see how in a theoretical hpx thread_data would be a basic building block that doesn't need to know about schedulers that actually schedule thread_datas? in practice we might not be able to achieve that
<heller>
Right
<heller>
That was the whole idea of the execution agent
<heller>
To have a layer in between...
<simbergm>
so just to be specific, you mean agent_base
<simbergm>
?
<simbergm>
execution_agent is the specific implementation for our coroutines and schedulers?
<simbergm>
and to be more specific, agent_base would be a layer in between what exactly?
<simbergm>
gtg, will read messages in a bit again
<simbergm>
so having thread_data, execution_agent, and scheduler_base in one module is definitely not so bad
<simbergm>
again I was just hoping to find a way to separate them, but that looks unnecessarily tricky
<heller>
Yeah
<heller>
Maybe for another round
<simbergm>
if you think it's a bad idea feel free to tell me
<simbergm>
yep, it's not so bad
<simbergm>
we can still keep the actual schedulers separate which is nice
<heller>
Right
<heller>
At one point in time, we need an interface like thread_data
rori has quit [Quit: WeeChat 1.9.1]
<hkaiser>
simbergm: so what's the plan for #4247?
<simbergm>
hkaiser: no decision yet, still wanted to hear your input (rori changed it to hpx/execution instead of hpx/execution/parallel but I'm not merging it yet)
<simbergm>
I see only two options
<simbergm>
keep it as it is (close without merging) or have the files in hpx/execution
<simbergm>
hpx/execution/parallel makes very little sense to me
<simbergm>
what was the reason for your "weakly" in favor? you'd rather not do it at all or you'd prefer a different name?
<hkaiser>
simbergm: I was just not sure about the benefit
<hkaiser>
the standard has those things in std::execution, so having it in hpx::execution would be sensible, in which case moving things to hpx/exection/ would be appropriate as well
<simbergm>
right, the directory change is purely to match the module name, so there's no direct benefit in that sense
<simbergm>
long term it's probably the right thing to do though
<hkaiser>
we could import everything in hpx::parallel::execution into hpx::execution to match the namespace to the directory structure
<hkaiser>
or everything from hpx::parallel into hpx:: proper
<hkaiser>
or physicly move things but import it back into parallel for compatibility reasons
<simbergm>
yes
<simbergm>
we still have some freedom with the algorithms since we haven't changed the header locations there
<hkaiser>
righ
<hkaiser>
t
<simbergm>
only thing I'm slightly unsure about is if we'd want to have actual executors in a separate executors module and as a result have them in hpx/executors
<hkaiser>
that's what we would like to have, in the end, yes
<simbergm>
and I don't want to move them before the release to one place and then after the release to another
<simbergm>
so in summary I'd like to see 4247 merged but after the release, gives us some freedom to still adjust things before the spring release
<simbergm>
hkaiser: khuck was looking for you yesterday btw (in case you haven't talked since then...)
<simbergm>
khuck: what's the status with the apex stuff now?
<hkaiser>
simbergm: it's Thanksgiving, I doubt he will respond today
<simbergm>
hkaiser: oh right... not in a rush, just realized he was online so I thought I'd ping him