08:16 <jbjnr> <hkaiser "if apply itself fails, throw an "> I don't want to throw an exception. why not allow apply to return whatever the underlying launch mechanism returns? we have a lot of code that calls cuda functions and checks the error code - octotiger/dca/linear algebra/others - we have a substantially new type of future with our new cuda / mpi / libfabric integration - they do not need to create tasks, but they execute

08:16 <jbjnr> asynchronously. being able to return a code from apply (or potentially from async as well) simplifies things greatly.

14:45 <K-ballo> so this thread label bimap isn't even being used

14:45 <hkaiser_> which one?

14:46 <K-ballo> the one from the thread mapper

14:47 <hkaiser_> I wasn't even aware that it's used there ;-)

14:47 <hkaiser_> well, we apparently need to look at this for yet another reason

14:49 <K-ballo> seems only register_thread/unregister_thread are being used, suspicious

14:50 <hkaiser> K-ballo: it's used for the PAPI counters

14:51 <K-ballo> are those held on some other repo?

14:53 <K-ballo> ah, no, they are opt-in

14:56 <K-ballo> ok I won't be touching that then

15:00 <hkaiser> K-ballo: linux only

16:21 <Yorlik> p/

16:21 <Yorlik> My keyboard hates me again.

16:22 <Yorlik> o/