aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<nikunj>
@hkaiser: The reason why many of hpx components disn't work in init_globally (even though main was registered as an hpx thread) is because get_self_ptr() is equal to nullptr
<nikunj>
That was the reason why most hpx components gave null id error at runtime
<nikunj>
@hkaiser: is there any hpx function which could assign the function a pointer and add it to the stack?
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
verganz has quit [Ping timeout: 260 seconds]
mcopik has quit [Ping timeout: 240 seconds]
<hkaiser>
nikunj: if get_self_ptr() == nullptr, then the calling thread is not an HPX thread
<hkaiser>
most of the functionality of HPX is available only to HPX threads
<nikunj>
@hkaiser: Then what is actually happening to main in init_globally?
<hkaiser>
nikunj: in HPX you have to distinguish between kernel threads (pthreads) and HP Xthreads
<hkaiser>
the kernel threads are the ones that are used to actually execute things, HPX threads are not really threads (in terms of the OS)
<hkaiser>
HPX threads are lightweight objects that behave semantically as if they were 'threads'
<hkaiser>
you can think about HPX threads as functions invoked on their own stack
<nikunj>
@hkaiser: so the main function is only registered as hpx thread in init_globally, right?
<hkaiser>
the main (kernel-)thread is not an HPX thread, but it is known to the runtime
anushi has quit [Ping timeout: 240 seconds]
<hkaiser>
non-HPX threads can invoke a select HPX functions if they are registered with the runtime
<hkaiser>
for instance they can schedule an HPX thread
<nikunj>
@hkaiser: ok
anushi has joined #ste||ar
<hkaiser>
nikunj: have you heard about user-level threading?
<nikunj>
@hkaiser: yes, but only superficially
<hkaiser>
that is what HPX has implemented
<nikunj>
@hkaiser: Now, I've understood
<nikunj>
@hkaiser: So we could only register main with the runtime, but can't use it fully as an HPX thread in init_globally
anushi has quit [Ping timeout: 240 seconds]
<hkaiser>
that is true for the thread that normally invokes the C-main function, but not for the function itself - that one could theoretically be executed by an HPX thread (and that is what you attempted to do)
anushi has joined #ste||ar
<hkaiser>
in your case, main() actually gets executed twice, I believe, once as an HPX thread (through hpx::init) and once through the normal startup sequence as a non-HPX thread
<nikunj>
@hkaiser: yes, that's exactly what I've done
<nikunj>
In my case, I first run the main function as hpx thread
<hkaiser>
yes
<nikunj>
once all work is done, I simply call the std::exit with an EXIT_SUCCESS, this let's the destructors to be called before exiting
<nikunj>
This way the C-main function is never executed
<nikunj>
But with my way, there is a problem, if a user wishes to define it's own global initializations, it will never be executed
<hkaiser>
nikunj: well, that's what you expected to happen
<hkaiser>
however, hpx::finalize does not block, it only signals to the runtime that it is ok to exit
<hkaiser>
so things move forward before your destructor is being called and main gets called again
<nikunj>
@hkaiser: Oh, no. This is not what I do
<hkaiser>
I think at least that's what happens, I have not run your example myself
<nikunj>
After the hpx::finalize, I define another struct
<nikunj>
In that struct's constructor I call std::exit
<hkaiser>
I saw that
<nikunj>
That's what signals the exit sequence after hps::finalize
<nikunj>
and blocks compiler's execution of main
<nikunj>
This way the compiler never get's a chance to execute main twice
<nikunj>
It's like I'm forcing the compiler to exit before main is actually executed by it. This is to prevent the main execution twice
<hkaiser>
ok
galabc has joined #ste||ar
<zao>
Is this at global scope to leverage static initialization?
galabc has quit [Client Quit]
<nikunj>
zao: yes
<hkaiser>
nikunj: this still leaves that other global objects might never get initialized
<zao>
Note that the order of such things is top-down per source file, but indeterminate between TUs.
<hkaiser>
zao: nod, exactly
<nikunj>
@hkaiser: yes, that's what I'm currently trying to tackle
<nikunj>
But currently I'm able to run multiple examples with ease
<nikunj>
I haven't received any errors as of now
<hkaiser>
nikunj: lucky you
<nikunj>
This includes factorial, sierpinski
<nikunj>
and few I don't remember
<hkaiser>
try creating a global object _after_ your manage_global_runtime to see that it breaks
<zao>
I have a feeling that if you in another source file define something global like `std::string x = []{ return "hi"; }();` the contents of `x` may be quite surprising.
<zao>
Or go with Hartmut's plan.
<zao>
(probably more reliable)
<zao>
(I'm trying to figure out how to write idiomatic Go)
<hkaiser>
zao: don't, just don't
<hkaiser>
;-)
<zao>
I'd consider HPX, but we all know no-one knows how to use it ;)
<hkaiser>
zao: right
<github>
[hpx] K-ballo force-pushed fmtlib from 62fac77 to 652ecba: https://git.io/vFHIw