Possibly unnecessary SkipQueue?

[vilacha]

I don't understand the "skipQueue" logic. Let's say that I want to have all my tasks to be "abortable". If I add a signal to all instantiations of a task, none of them goes into TaskQueue, they all are inside "skipQueue". Looking into the source code, one can see that aborting a task kills the thread when needed or removes the given task from TaskQueue, which is what the user would expect. To me skipQueue seems to be unnecessary. Abortable tasks should not have a greater priority. I think this behaviour should be reconsidered. As it is right now it is imposible to build a queue with cancellable tasks, only possible when returning at least 1 in the size method of a custom queue.

[metcoder95]

I agree that about the fact that having a separated queue for abortable tasks, somehow disregards the benefits of the TaskQueue as they are not subject to the TaskQueue logic.

Nonetheless, Abortable Tasks (due to its nature), has a pretty situation here, as by design they will teardown the worker in case the tasks gets aborted, and for instance needs to be isolated from the rest of tasks as the worker should not be running another kind of task if the abortable one is taking place.

Adding this difference in semantics into a single can, it kind of opens a set of problems that we will need to deal with.
Situations like busy workers, and abortable on top of the queue, if no worker is able to get fully empty, queue will be halted undefinitely (unless we set semantics to re-queue or expire the task in the queue).

We can offload that decision to the TaskQueue implementation itself, but what should be the default behaviour from now on?

It is indeed and interesting situation while mixing both of them in the same can.

[vilacha]

I get your perspective. I think everything should be delegated to the main queue. As it is right now, if I happen to have a single task in the main queue, then all "abortable" are redirected there. I think this behaviour is inconsistent.
As for which default behaviour from now on... you know your user base better than I do. In my view, removing the "skipqueue" would not cause any impact on current users and it will be mostly welcome:

1. Aborting a task will either cause a thread to be cancelled when the task is already being processed, or the removal of the task from the main queue.
2. By default everybody expects a FIFO queue, and this behaviour will be maintained.
3. Users than have a custom queue can operate their task stack, by sorting by priority, dequeuing a collection of task according to some criteria... it would be so nice to have access to all queued task. As it is right now, there some task that are hidden.

[metcoder95]

I think this behaviour is inconsistent.

Agree

Your points are pretty valid, but breaking the semantics as is it already imposes a breaking change in all rules.
I'll feel safer if this is included within the next major.

The plan would be:

1. Abortable tasks gets enqueued into the TaskQueue itself

There are several situations to handle with the Abortable tasks is, e.g. if the Abortable task is being aborted through AbortSignal.timeout, time is ticking. Is possible it gets aborted without having the chance to be executed.
Nonetheless, it might be ok to keep it like this but document the possibility.

2. Current Task queue behaves the same, just Piscina gets rid of the internal buffer queue.
3. Add it as major.