Make work stealing from other schedulers optional #41

D4ryus commented 2020年07月11日 11:09:36 +02:00 (Migrated from github.com)

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.

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.

emixa-d commented 2023年09月04日 14:54:57 +02:00 (Migrated from github.com)

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

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

D4ryus commented 2023年09月04日 20:08:29 +02:00 (Migrated from github.com)

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.

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.

emixa-d commented 2023年09月18日 09:27:30 +02:00 (Migrated from github.com)

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.

>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.

This pull request is broken due to missing fork information.