<heller>
jbjnr: ahh, decoupling yield/suspend/resume from HPX threads
<jbjnr>
that's yielding to the OS rather than yielding an hpx frame?
<heller>
jbjnr: no, both
<heller>
jbjnr: one sec
<heller>
jbjnr: the idea is to gain the ability to have execution contexts that do not depend on any implementaion
<heller>
jbjnr: so OS threads would be one implementation, HPX threads another one, an openmp thread pool a different one, a kokkos thread pool might be an option as well
<heller>
jbjnr: the synchronization primitives like spinlock, mutex, condition_variable etc. only depend on the execution_context then ;)
<heller>
et voila
<heller>
you have a massively powerful instrument at your hand, that is all the niceness from hpx::future, independent of the HPX thread pools
<heller>
simbergm will like that
<heller>
makes your lifes easier...
<heller>
and improves performance
<jbjnr>
gosh - I must have been looking at the wrong gist
<heller>
no, this gist is the base of it
<jbjnr>
I was teasing. the gist just has empty suspend/yield functions ...
<heller>
indeed
<heller>
it's the unit test for the execution_context
<heller>
and by definition, the execution_context can not depend on hpx::thread_data and friends ;)
<Yorlik>
I defined ptr_t as using ptr_t = std::unique_ptr<T, myDeleter_>; and used ptr_t later in the class template as a return type and got the error message that a unique ptr need a template argument. Isn't the using enough? "T" is already known from t he template instantiation at that point.
<zao>
Yorlik: Did you do `template <T> using ptr_t = std::unique_ptr<T, myDeleter_>;` ?
<zao>
(err, template <typename T>, I don't do C++ nowadays)
nikunj has joined #ste||ar
<zao>
You may want to construct a godbolt example that illustrates the problem, or figure out why the example works and your code doesn't :)
<Yorlik>
Uh - just received an answer - myDeleter_ was an object not a type
<zao>
Pondered suggesting that, good :D
<Yorlik>
:D
<Yorlik>
Hmm .. this is tricky ... I'm trying to create an object pool hosting unique pointers to objects, where the objects are automagicall returned to the pool in the custom deleter.
<Yorlik>
Somehow the deleter needs a reference to the pool.
<Yorlik>
But if it's just a type ...
<Yorlik>
myDeleter_ in the example above is a functor and I had a pointer to the pool in a constructor argument, but obviously his is a naive approach that doesn't work.
<zao>
You can supply an instance of the deleter type in the unique_ptr ctor.
<Yorlik>
OK - then it's getting inefficient.
<Yorlik>
I think I need to use statics here.
<zao>
You need to express the type of the deleter in the type definition of the unique_ptr, and either work with default-constructed or provided instances.
<Yorlik>
I could make a static instance in the pool.
<Yorlik>
I could make all the return and acquire stuff and the vector holding the objects static too
<Yorlik>
Would make it practically a singleton type of thing.
<Yorlik>
I should maybe make one static pool per thread as a thread_local static.
<Yorlik>
Gotta think over all this.
<zao>
Thinking before you implement - a novel concept :D
<Yorlik>
However: thanks zao :)
<Yorlik>
At least try hard to pretend I'Äm thinking at times.
K-ballo has joined #ste||ar
aserio has joined #ste||ar
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 244 seconds]
nikun__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 268 seconds]
weilewei has quit [Ping timeout: 245 seconds]
nikunj has joined #ste||ar
nikun__ has quit [Ping timeout: 268 seconds]
jaafar_ has joined #ste||ar
hkaiser has quit [Quit: bye]
jaafar_ is now known as jaafar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 268 seconds]
K-ballo1 is now known as K-ballo
weilewei has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
aserio has joined #ste||ar
nikunj has quit [Ping timeout: 268 seconds]
hkaiser has joined #ste||ar
nikunj has joined #ste||ar
aserio has quit [Quit: aserio]
<diehlpk_work>
hkaiser, We need to devote more time for graduate training. Do you have some course materials about AMT or HPX?
<hkaiser>
diehlpk_work: the summer lectures?
<hkaiser>
we could propose doing more of those
<diehlpk_work>
Ok, I also ways thinking to start a graduate seminar at our group
<diehlpk_work>
So older graduate students will teach git, slurm, and other tools to new students
<diehlpk_work>
We might want to add this as well or?
<hkaiser>
sure, nice ide
<hkaiser>
a
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
jaafar has quit [Client Quit]
jaafar has joined #ste||ar
jaafar has quit [Client Quit]
jaafar has joined #ste||ar
nikunj has quit [Ping timeout: 245 seconds]
<diehlpk_work>
hkaiser, I added two small paragraphs to Section 5. Would be nice if you can have a look and extend the idea of the new summer lecture about HPX