fibers icon indicating copy to clipboard operation
fibers copied to clipboard

Make work stealing from other schedulers optional

Open D4ryus opened this issue 5 years ago • 3 comments

When working with multiple fibers and ports, disabling work-stealing makes it easier to ensure only one thread is accessing a given port. E.g. this allows a fiber to spawn additional fibers to access a port without running into issues.

D4ryus avatar Jul 11 '20 09:07 D4ryus

What issues would these be? Is this for performance only (cache locality etc.), or any bugs?

emixa-d avatar Sep 04 '23 12:09 emixa-d

Ran into bugs when multiple threads accessed the same port, but i don't remember the details, sorry. Guile ports changed a lot since this PR was opened, it might be obsolete by now. Feel free to close it if there is no interest in making work stealing optional.

D4ryus avatar Sep 04 '23 18:09 D4ryus

When working with multiple fibers and ports, disabling work-stealing makes it easier to ensure only one thread is accessing a given port. Ran into bugs when multiple threads accessed the same port, but i don't remember the details, sorry.

How about implementing CPU pinning (https://en.wikipedia.org/wiki/Processor_affinity) instead (the strict version, not the ‘can also move to other CPU/core/whatever)? It avoids the implementation detail that is work-stealing, is more general (you could assign multiple fibers to the same (or different) CPU/core/..., whereas with this implementation you need to be lucky that multiple fibers have the same/different CPU/core/...) and is known (outside Fibers) to occasionally be useful ...

Basically the same thing as the current implementation, except that ‘work-stealing?’ becomes a per-fibers flag, ‘spawn-fiber’ gains an extra option indicating it should be strict about the scheduler choice and run-fibers gains an option to bind the schedulers to specific CPUs/cores/whatever.

emixa-d avatar Sep 18 '23 07:09 emixa-d