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]
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
<mdiers[m]>
I have a problem with server/client_base and rather ask once before I search long, maybe it was already known:
<mdiers[m]>
A future<> created with async<action> does not get a has_value status on the server side, although on the client side the call was completed. A call takes several minutes.
<mdiers[m]>
The clients running on the same node as the server do not have this problem.
<hkaiser>
mdiers[m]: not quite sure what your problem is
<mdiers[m]>
in short: future<> does not get a finished status although the task was processed on the client side.
<K-ballo>
are you saying after a call of the form `auto fut = async(foo);`, the future `fut` isn't ready?
<mdiers[m]>
yes, the first few times it still works, but after e.g. one hour there is no answer anymore
<mdiers[m]>
s/answer/ready/
<mdiers[m]>
* yes, the first few times it still works, but after e.g. one hour there is no ready anymore, except the ones called on the same node
<K-ballo>
it's normal for the future to not be ready immediately after an asynchronous call
<K-ballo>
but once a future is ready it can never go back to not ready, that sounds suspicious
<mdiers[m]>
ah ok, i must check also has_exception. Currently i checked only has_value. Maybe I'll get a little more out of it.
<K-ballo>
are you checking in a context in which you know the future to be ready?
<K-ballo>
like inside a continuation: fut.then([](future fut){ fut.has_value() })?
<mdiers[m]>
No, it is a simple scheduler. I wait in loop with wait_any(), get the results from has_value() and replace then the feature<> with a new one.
<K-ballo>
you should be checking for is_ready()
<K-ballo>
> The function wait_any returns after at least one future has become ready.
<mdiers[m]>
<mdiers[m]> "ah ok, i must check also..." <- No is_ready although it was processed on the client side, except the ones called on the same node.
<mdiers[m]>
K-ballo: Yes I replaced it
<K-ballo>
I don't know what you mean by "processed on the client side", but if wait_any returned then at least one future must be ready, else you are looking at a bug
<mdiers[m]>
"processed on the client side" -> components::client_base<>::myasyncactioncall()
<K-ballo>
it could execute to completion before `async` returns, but more likely it wont
<K-ballo>
the future will only be ready once the asynchronous execution completes
<mdiers[m]>
K-ballo: The asynchronous execution completes but the future gets no ready status.
<K-ballo>
ok, that's new information, how do you determine it has completed?
<mdiers[m]>
Is there a possibility to trace the communication between components::client_base and components::server_base somehow. Or the possibility to trigger the communication again somehow to sync/verify? It is also possible that it is some mpi/etc problem.
<mdiers[m]>
An log entry at the end of the called function. 🙈
<K-ballo>
so the log line makes it all the way back to the "client", but the result doesn't? interesting
<mdiers[m]>
Yes, but I'm sure it's because we don't use it normally. A call lasts about 5 minutes and includes opencl (directly without hpx) ;-)
<K-ballo>
it's not a context in which lifetime extension happens
<K-ballo>
the note is making you aware of that, the function itself rejects nothing
<K-ballo>
you may use temporaries with it, be aware their lifetimes are not extended
<gonidelis[m]>
it does not "not extend their lifetime" ?
<gonidelis[m]>
ok but why?
<K-ballo>
...the question makes no sense
<gonidelis[m]>
why is the lifetime not extended?
<K-ballo>
because that's just not how lifetime extension works
<K-ballo>
lifetime extension happens when you bind a temporary directly into a reference
<K-ballo>
when you use forward_as_tuple you are binding a temporary to the reference from the parameter, and then binding the returned tuple's member reference into the parameter from the parameter
<gonidelis[m]>
why not being able to use `std::tuple<int,int>a = std::forward_as_tuple(10, 20)`
<gonidelis[m]>
?
<K-ballo>
you just made that up, there's nothing wrong with that line
<K-ballo>
the temporaries do NOT get lifetime-extended
<gonidelis[m]>
my bad
<K-ballo>
auto&& ref = 10; // the materialized temporary that holds 10 is lifetime extended (its lifetime extends to the scope of ref)
<K-ballo>
auto&& ref = std::move(10); // the materialized temporary that binds to move's function parameter is NOT lifetime extended (dies at the semicolon)
<K-ballo>
that's all the note in forward_as_tuple is saying
<gonidelis[m]>
`auto&& ref = std::move(10);` but i can use `ref` after the semicolon, right?
<K-ballo>
it's UB
<K-ballo>
it references an object out-of-lifetime
<gonidelis[m]>
dangling ref!!!!???
<gonidelis[m]>
ohh
<gonidelis[m]>
i still do not understand the reason why we selected to do it like that, but i do understand that it is like that
<K-ballo>
it's not immediately feasible to do it differently
<gonidelis[m]>
ok
<K-ballo>
you can't in general detect that the object a reference points to has died
<K-ballo>
you could lifetime extend the temporary in this case too, if `std::move` were annotated with a special keyword
<K-ballo>
because otherwise you have no way of knowing that the reference move returns points to the object from its argument
<K-ballo>
there was a good proposal for that, but it didn't gain traction
<gonidelis[m]>
amazing
<gonidelis[m]>
actually sounds like it was only fair for the proposal to go down. it seems cogent to me that it actually works that way now ;p
<K-ballo>
meh, it does make sense to extend the lifetime-extension mechanism, but it requires annotating the world.. not practical, unless you are starting from scratch (and even then...)