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
K-ballo has quit [Quit: K-ballo]
diehlpk_work has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
tufei__ has quit [Quit: Leaving]
tufei has joined #ste||ar
FunMiles has joined #ste||ar
FunMiles has quit [Quit: Connection closed]
FunMiles has joined #ste||ar
<FunMiles>
What is the proper way to initialize the HPX run-time from an app that mostly is unaware of HPX?
<FunMiles>
Is it mandatory to have an `hpx_main` function if I call `hpx::init` ?
<FunMiles>
`hpx::start` I meant
<zao>
As I understand it, hpx_main is a bit of a convenience thing that's run when you convert a regular (main) thread into a HPX thread, to make it easy to transition into being a HPX task.
<zao>
Some of the matrix of startup functions lets you keep the current thread how it is and instead spin up others, but I don't remember how to do that or actually feed them work.
<FunMiles>
I'm trying now to look at the example init_globally
<FunMiles>
And I am even more confused. It does not have any call to hpx::init and there's a comment saying:
<FunMiles>
// The main thread was automatically registered with the HPX runtime,
<FunMiles>
// no explicit registration for this thread is necessary.
<FunMiles>
It's even more confusing because this example is supposed to illustrate what to do if HPX is used in a dynamically loaded library. Yet there is a main and the above two lines of comment.
<FunMiles>
I guess that's done by the global 'init' variable.
<zao>
HPX also has a static library that can be linked into your application which hooks into your process to initialize HPX early and turn your actual main transparently into a hpx_main). Some of the CMake machinery can do this for you.
<zao>
Been a while since I dug in this, you may get more current and accurate responses later on.
<FunMiles>
I've noticed that when I do a linking from CMake, a hpx initialize_main is what calls my main....
<FunMiles>
But I can see having a use for initializing HPX from a dynamically loaded library.
<zao>
In a dynamic library, it may be using global ctors/dtors at a linker level, if memory serves me right.
<zao>
Similar to a regular global, but with more predictable init order.
<FunMiles>
Looking at the code from the init_globally example, I am a bit puzzled by the use of thread_local static variable, though for the actual code as it, I understand it, but for a use where one thread might want to call hpx functions and then another one might as well, if the first one dies, it seems the hpx runtime will die.
<FunMiles>
For the exact demo, that's actually something the demo wants to demonstrate.
<FunMiles>
I think that for dynamic library, global variable are initialized at load time and destroyed either at the end of the execution or when the library is unloaded.
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
<FunMiles>
I got my code working with some of the tools from init_globally. My main remains unaware of HPX. No call from initialize_main.