You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This requires #55 and describes a potential approach.
The idea is that recursion functions like QuickSort can be implemented with a manual or automatic task scheduling similar to what the TPL supports (ContinueWith).
This requires that a task executed in the worker can schedule workers itself. requiring the parallel library again is possible, however, each worker uses than its own thread pool that spawns new workers...
To avoid this, a centralization of the thread pool information idea is.
A potential solution is to use SharedWorkers instead (if supported) allowing a communication between the workers. A sharred worker can be identified by a name. To maintain the Worker-State information (needed by the thread pool), a shared array buffer can be used (again, if supported). This buffer maintains which worker currently is idle and which are not (if work stealing is used, potentially how many tasks are queued in this task).
If SharedArrayBuffers are not supported, a main worker is needed that plays the roll of a master / coordinator and is just responsible to answer a worker which next worker is free (if any).
If neither of both technologies are supported, Recursion might still be possible but always requires a round trip back to the main thread.
This enables Continuation Support, Recursion Support and potentially a work stealing thread pool
The text was updated successfully, but these errors were encountered:
This requires #55 and describes a potential approach.
The idea is that recursion functions like QuickSort can be implemented with a manual or automatic task scheduling similar to what the TPL supports (ContinueWith).
This requires that a task executed in the worker can schedule workers itself. requiring the parallel library again is possible, however, each worker uses than its own thread pool that spawns new workers...
To avoid this, a centralization of the thread pool information idea is.
A potential solution is to use SharedWorkers instead (if supported) allowing a communication between the workers. A sharred worker can be identified by a name. To maintain the Worker-State information (needed by the thread pool), a shared array buffer can be used (again, if supported). This buffer maintains which worker currently is idle and which are not (if work stealing is used, potentially how many tasks are queued in this task).
If SharedArrayBuffers are not supported, a main worker is needed that plays the roll of a master / coordinator and is just responsible to answer a worker which next worker is free (if any).
If neither of both technologies are supported, Recursion might still be possible but always requires a round trip back to the main thread.
This enables Continuation Support, Recursion Support and potentially a work stealing thread pool
The text was updated successfully, but these errors were encountered: