hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu | Everybody: please respond to the documentation survey: https://forms.gle/aCpNkhjSfW55isXGA
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 272 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Read error: Connection reset by peer]
diehlpk_work has quit [Remote host closed the connection]
<ms[m]>
gnikunj: I think the confusion might just be due to bad naming
<ms[m]>
the thread_data in that test is exactly the "user-provided" thread data that hkaiser mentioned earlier
<ms[m]>
not sure if that's what you're thinking about
<ms[m]>
there's also the thread_data which holds the actual thread stack, priority, annotation, etc. etc.
<gnikunj[m]>
Yes, I want to add data to a thread using those 2 functions. The functions accept std::size_t so we have to do a reinterpret case to convert to send in a 64bit pointer. I wanted to ask who manages the deletion of the pointer that we're setting in the thread?
<gnikunj[m]>
does it get deleted within the destructor or are we as the user supposed to manage the pointer?
<ms[m]>
you are, there's no way for the thread itself to know how or what you want to be deleted
<hkaiser>
I can't even compile the thread_pool_scheduler test with msvc :/
<ms[m]>
hkaiser: yeah, sure, I'll try to have a look (not immediately, but this week for sure)
<ms[m]>
that's your refcounted thread data pr, right?
<zao>
Breaking MSVC? I'm amazed and surprised ;)
<hkaiser>
ms[m]: yes
<hkaiser>
zao: never happened before - and yet again
<zao>
cd ..
<zao>
<_<
<zao>
The Windows 11 terminal is a bit weird in how it renders the caret, thought I had focus.
<zao>
Ah, you need C++17 to get that test included, explains why I was missing it with the default C++14 on MSVC.
<zao>
I'm guessing this is what hkaiser sees? C:\stellar\hpx-pr5441\libs\core\execution_base\include\hpx\execution_base\sender.hpp(718): fatal error C1202: recursive type or function dependency context too complex
<zao>
(this on VS 16.10.3)
<zao>
Not specific to the PR, btw.
qiu has joined #ste||ar
<hkaiser>
zao: yes
<hkaiser>
yes, that must have been introduced recently as I was able to compile things before :/
<zao>
Not sure how much we care about prerelease VS versions tho :)
<zao>
Well, not earlier, different.
<zao>
(concurrent ninja output tricked me)
<zao>
Ah no, it's the same error, just with more/different context.
diehlpk_work has joined #ste||ar
<ms[m]>
"context too complex" 😢
<hkaiser>
zao: yes, I have seen that as weel, this is caused by a change I made to the sender/receiver when_all algorithm
<hkaiser>
I have not found the cause for the actual 'too complex' problem yet
<ms[m]>
I can go ahead and remove the implicit executor as scheduler or vice versa stuff from the cpos, that might help (I want to do it anyway, so worth a try)
<hkaiser>
will bisect
<hkaiser>
ms[m]: nah, it worked before
<zao>
My curiosity whether I could reproduce it has been satisfied :)
<hkaiser>
let me find the culprit first
<ms[m]>
👍️
<hkaiser>
zao: thanks
<ms[m]>
hkaiser: I'll go ahead with the release announcement in any case now
<hkaiser>
ms[m]: sure
<ms[m]>
we can do a patch release again soon if we manage to get that fixed
<gnikunj[m]>
hkaiser: I see :/ I spent 3h building tests on my laptop only to be told an assertion error that i need to run on more than 1 locality ;_;
<gnikunj[m]>
let me reproduce it on rostam and see
<hkaiser>
gnikunj[m]: nah
<hkaiser>
you can run it on your laptop
<hkaiser>
hpxrun -p 2 -t 1 ./executable
<gnikunj[m]>
let me try that
<zao>
I noticed something odd trying to run tests on my Windows machine, a lot of the early tests try to invoke just hpxrun.py, with no arguments.
<zao>
Not sure if that's by design and the results are ignored somewhere.
<gnikunj[m]>
hkaiser: I can't reproduce ASAN on my machine :/