Current thread_id changing after suspending in direct execution about hpx

[hkaiser]

@Pansysk75 Yep, that's caused by the direct execution patch. cancelable_action should call get_outer_id instead (here:

hpx/examples/cancelable_action/cancelable_action/server/cancelable_action.hpp

Line 61 in bc993dd

outer_.id_ = hpx::this_thread::get_id();

). Excellent catch!

[hkaiser]

@Pansysk75 Yep, that's caused by the direct execution patch. cancelable_action should call get_outer_id instead (here:

hpx/examples/cancelable_action/cancelable_action/server/cancelable_action.hpp

Line 61 in bc993dd

outer_.id_ = hpx::this_thread::get_id();

). Excellent catch!

I just realized that we don't have that - what an oversight! It should be added here:

hpx/libs/core/threading/include/hpx/threading/thread.hpp

Line 284 in bc993dd

HPX_CORE_EXPORT thread::id get_id() noexcept;

and here:

hpx/libs/core/threading/src/thread.cpp

Lines 386 to 389 in bc993dd

	thread::id get_id() noexcept
	{
	return thread::id(threads::get_self_id());
	}

The new code should be:

        thread::id get_outer_id() noexcept
        {
            return thread::id(threads::get_outer_self_id());
        }

[Pansysk75]

That should work, but as a user I would really wonder what "outer" refers to and why I should use that (if I didn't know the implementation details).
I was thinking of perhaps modifying the yield operation so that the state before and after the yield would be the same, if that is at all possible. That should make 'hpx::this_thread::get_id()' return some constant id (the one of the thread being "directly executed" i suppose)
Is there a good reason why a different id should be reported right after suspension? Is it a bug or is it something that we expect?

[hkaiser]

Alternatively we could make the current implementation of get_id call the get_outer_self_id instead. Not sure what this would break, though...