On 28/09/2023 05:09,
oliver....@gmail.com wrote:
> Yoi can't move a runnong fiber to anotjer thread. A fiber is simply a stack (+ some registers) that is assigned a thread for execution.
Boost.Fiber's own work stealing scheduler moves fibers between threads.
They can't be running at the time for obvious reasons, they get their
context suspended, then you detach() the suspended context on the source
thread, then it gets attach() on the destination thread, then execution
is resumed.
Apart from GDB showing worryingly incorrect stacktraces after thread
migration for the stack preceding fiber creation, this works fine. I'm
currently using a condvar's wait_queue to do the suspension and
resumption, and a helper fiber to do the context detach and reattach
across kernel threads.
Which brings me back to my original question:
>> But now you're creating and destroying a whole Fiber just to migrate a
>> Fiber between kernel threads, and that feels icky.
>>
>> I don't suppose there's a better way e.g. some sort of way of asking the
>> current thread's Fiber scheduler to call a function when it's next not
>> executing a Fiber? That would avoid the needless Fiber creation and
>> destruction per migration of a Fiber across kernel threads.
I can create a custom scheduler and that solves the problem without
issue without any inefficiency. But that's effort.
I can use a thread local stack of items to pop off and execute next time
the fiber scheduler exits back to normal code per kernel thread, but
that's effort and requires a whole bunch of malloc and it's intrusive.
I can create a helper fiber to do the thread migration for me, but that
wastes a fiber per kernel thread.
I guess what I'm wondering is how come boost::fibers::wait_queue isn't
documented, and why can't I have lightweight context which doesn't
contain any actual stack nor other gubbins, and just calls some callable
per scheduler invocation?
I appreciate Boost.Fiber is very mature nowadays, so I'm not asking for
new features or a substantial refactoring. I guess I really just want a
maximally efficient way of manually moving a Fiber across kernel threads
just like I can with a suspended C++ coroutine, and I don't currently
see one in Boost.Fiber?