Revert "Using atomic instead of mutex and delete scratch slice" #1846
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reverts #1833
The new implementation of the workerChan queue has the following issues:
The original implementation used push operations for enqueuing and pop operations for dequeuing, while the new implementation uses unshift operations for enqueuing and shift operations for dequeuing. This difference doesn't align with the original design, although this issue might not be significant on its own.
When cleaning up the workerChan queue, the new implementation does not support pop operations. Instead, it uses unshift operations to inspect whether a workChan is active. As a result, old workChan instances cannot be removed unless the youngest one in the queue has also expired.
The solution for issue one related to enqueuing has led to the problem where the cleanup task in issue two cannot be correctly implemented.
A single-headed unidirectional queue cannot fully replicate the original mutex-based workChan queue. When addressing the workChan queue issue with a lock-free linked list, we may need to consider more aspects carefully.
I am sorry to submitted a pull request opposing the previous one because the potentially buggy code has already been merged into the master branch. We need a better solution to the existing issue before considering merging it back into the master branch.