<hkaiser>
may I ask you to hold of for a while on #4026
<hkaiser>
I'm not sure I like those changes and would like to have some time to think about this
<simbergm>
yeah, sure
<simbergm>
what do you not like? ;)
<hkaiser>
the thread constructors that take the pool
<hkaiser>
while I understand what you would like to achieve I'm not sure if this isn't putting the cart before the horse
<hkaiser>
but there might be mo other way *sigh*
<simbergm>
all right, what specifically about that are you worried about?
<hkaiser>
in std space a thread_pool _uses_ a thread (that's because there is only one default 'pool' of threads - the OS
<hkaiser>
we might _have_ to specify somehow what 'pool' to use to create a thread - so I see what you are doing
<hkaiser>
since we refactor things anyways, let's look at some design documents the committee has produced
<hkaiser>
let me dig that out
<simbergm>
ok, thanks
<simbergm>
but wasn't this backwards before as well then? I'm just making the choice of thread pool explicit... but I can see how you might want to change things into a more "standard" direction
<hkaiser>
not saying it was ok before ;-)
<simbergm>
ok, just wanted to clarify...
<hkaiser>
can't find that document I'm looking for
<hkaiser>
it had a nice taxonomy and a hierarchy of the terminology thread context, thread pool, executor, thread, etc.
<hkaiser>
(even if the proposal didn't go anywhere)
<simbergm>
hkaiser: unrelated question: did you use clang-format-7 or 8 for program_options? I'm seeing a lot of differences in the formatting, don't want to go and apply the wrong formatting changes...
<hkaiser>
simbergm: I don't know :/
<hkaiser>
also, I think I left some of the options descriptions unformatted
<hkaiser>
stupid me, should have added the comments
<simbergm>
no worries, I'll add them :)
<simbergm>
thanks for the paper
<hkaiser>
thanks
<simbergm>
doesn't (part of?) the difference between the linked threads and our threads come from our thread pools dealing with coroutines/thread_data/thread_init_data and thread being exposed as a concept built on top of that?
<hkaiser>
wg21.link/p0320 has the most updated version
<simbergm>
thanks, I'll have a look through that
<hkaiser>
there is an alternative proposal wg21.link/p0484
<hkaiser>
can't find the document I have in mind - might have been presented in one of the phone calls :/
<heller>
our current thread_data is kind of everything together
<heller>
and on top of that, we have an additional hpx::thread class
<heller>
our user level thread would be the execution context, IIRC, hpx::thread should abstract from that and allow for alternative implementations, for example non-suspendable tasks etc.. To build an execution context, you would build an executor (with appropriate properties) on the thread pool you created from your resources. The executor is then responsible to create the thread, which might be completely hidden when spawning tasks with async or the like
<heller>
this would nicely abstract the concept the actual scheduling away from the concept of a thread. The properties (like affinity, stack space etc) would be handled by the executor, the scheduling by the thread pool.
<heller>
The execution context, provided by either a thread pool, OS threads or whatever, is then responsible for suspending/resuming (if it should be allowed at all) of the underlying thread of execution
<rori>
hkaiser: first cmake pb solved but I have a new one, the template for package config is written multiple times with msvc since it is building several build configurations at the same time, I would like to make the name of the generated template depend on the detailed configuration (_release and _debug not sufficient), would you know which variable could I use, I don't know nothing about windows env ^^
aserio has joined #ste||ar
<rori>
hkaiser: other question, is there any pkgconfig user who are on windows ?
<hkaiser>
rori: no pkg-cfg on windows
<rori>
Ah great :D
<hkaiser>
you can remove support for pkg-cfg on windows alltogether
<hkaiser>
we just never bothered to remove it ;-)
<hkaiser>
well, if somebody is crazy enough to use cygwin or similar, that would still be usable, but nowadays with WSL in place this is a no issue, I believe
nikunj has quit [Remote host closed the connection]
<zao>
I'
<zao>
I'd expect anyone running msys to use pkg-config, considering that that ecosystem is pretty much using pacman (from Arch)
<zao>
Now whether there's HPX users using it, that's a different question, but it's a legitimate environment and there's occasional reasons to target it rather than MSVC.
nikunj has joined #ste||ar
<hkaiser>
zao: even if there is WSL nowadays?
<zao>
Sure, completely different domains.
<hkaiser>
right
<zao>
WSL doesn't help you if you're building Windows-native code, but need/want a GNU toolchain.
<hkaiser>
indeed
<zao>
There's less need for it, but still a need.
<hkaiser>
let's cross that bridge if somebody needs to
<zao>
Some IDEs are mingw-centric too, like JetBrains and QtCreator, even if they're somewhat capable of MSVC.
<hkaiser>
I'd say we drop support for pkg-config on windows for now
<zao>
Just something to keep in mind for the future :)
<hkaiser>
right
<zao>
This is for using HPX via pkg-config, right?
<zao>
For novel code, I'd expect/hope people would use the exported CMake junk.
<zao>
Whatever workflow we're trying to encourage on Linux.
<rori>
My problem : I'm building in the x64-Debug configuration (for example) and I configure a template which contains generator expressions and I then generate this template to replace generator expression, and it is complaining about writing multiple time this files (cause the generator expressions probably differ but I don't know which one or any variable that could help me personnalize the file name to the
<rori>
configuration)
<rori>
zao: any ideas ?
<zao>
Nah, my CMake usage pretty much boils down to copy-pasting StackOverflow answers :)
<rori>
Haha try that but no solution for this problem xD
<rori>
tried*
<zao>
Maybe there's a way to disable it if you detect somehow that you're on a multi-configuration type of generator?
<rori>
Yep but I don't know how to detect that in my cmake code ^^
<zao>
"future work"
<hkaiser>
rori: you will need separate files for this
diehlpk has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
<rori>
hkaiser: yes !
<rori>
zao: xD
rori has quit [Quit: bye!]
aserio has joined #ste||ar
<hkaiser>
simbergm: you still there?
nikunj97 has joined #ste||ar
<heller>
hkaiser: did you see my threading/executors/thread pool mumblings?
nikunj has quit [Ping timeout: 246 seconds]
<diehlpk>
simbergm, Do you want to attend the meetings with Rebecca every week or just if we need you?
<hkaiser>
heller: I have not
<hkaiser>
let me read back
<heller>
I think, eventually, we should take the chance of refactoring to make it right. We carry to much technical debt due to the hidden global scheduling stuff, IMHO
nikunj97 has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<hkaiser>
heller: I agree
<diehlpk>
hkaiser, see pm The answer to the first question would help, since I can not check out the student's submissions for grading
<heller>
The papers I linked are all related, but not entirely coherent yet
<heller>
But I do remember that taxonomy paper you mentioned as well...
hkaiser has quit [Quit: bye]
david_pfander1 has joined #ste||ar
david_pfander1 has quit [Client Quit]
aserio has quit [Quit: aserio]
hkaiser has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 245 seconds]
K-ballo1 is now known as K-ballo
diehlpk has quit [Ping timeout: 264 seconds]
K-ballo has quit [Remote host closed the connection]