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
Yorlik_ has joined #ste||ar
Yorlik__ has quit [Ping timeout: 265 seconds]
hkaiser has quit [Quit: Bye!]
tufei has quit [Remote host closed the connection]
tufei has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
Arnav-Negi has joined #ste||ar
Arnav-Negi has quit [Client Quit]
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
beojan has joined #ste||ar
<beojan>
Hi. I'm trying to pass a lock on a mutex into an asynchronously exxecuted lambda by capturing an `std::unique_lock` with `[lck=std::move(lck), eventIdx, evtSel, ctx] () mutable`. However when this goes through HPX_FORWARD (as part of hpx::async) it seems it tries to wrap it in another lambda, which fails to compile because it tries to copy by capture instead of by move.
<hkaiser>
beojan: capture the lock using std::ref(l)
<hkaiser>
i.e. [lck = std::ref(lck)]
<hkaiser>
or capture it by ref: [&lck]
<hkaiser>
both require however that the lock stays alive until the lambda is executed
<hkaiser>
alternatively pass it through as an additional argument: async([](auto&& lck, ...) {}, std::move(lck), ...)
<hkaiser>
beojan, also, do you move the lambda into async? that should help as well
<beojan>
I can't guarantee the original lock will stay alive until the lambda gets executed. Moving the lambda into async (and sticking to capture by move) seems to at least compile.