KEMBAR78
Fixes #32264 - Allow N instances of the same task by alpalla · Pull Request #89872 · microsoft/vscode · GitHub
Skip to content

Conversation

@alpalla
Copy link
Contributor

@alpalla alpalla commented Feb 2, 2020

Summary

  • These changes allow N instances of the same task to be run simultaneously.
  • The maximum number of allowable instances can be set in RunOptions.
  • The instances of a task are visible in the QuickPick with an (i) appended to the quick pick entry label to indicate that the task is an instance of an already running task.
    For example if 3 instances of task foo are running, the QuickPick would display:
foo
foo (1)
foo (2)

Implementation notes

Distinguishing between multiple instances of the same task

When a task is run in terminalTaskSystem, if another instance can be created, the task that the user selected is cloned and its id is modified to have form <ORIGINAL_TASK_ID>|<COUNTER>.
The counter gets incremented each time an instance of the same task is created. The cloned task is then run like any other task.
This makes it possible to check if a task is an instance of another task because all instances of a task will have the <ORIGINAL_TASK_ID> substring in common in their respective ids.

Tracking multiple instances of the same task.

The <ORIGINAL_TASK_ID> substring shared by all instances serves as the key in a dictionary where the value is an InstanceManager object that stores information related to all instances of a task such as the number of currently active instances.

How to test changes

Create a tasks.json and set the instances property. Here is an example configuration:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "sleep 20 && echo Hello",
            "runOptions": { "instances": 3}
        }
    ]
}

You can then execute the echo task, ensure that it never runs more than 3 instances of itself and that if a 4th instance is attempted, you should be prompted to either terminate or restart the last instance of echo.

…e task.

If another instance of a task is run, a clone of that task will be created and its ID will be modified by appending '|<COUNTER>' to the original task ID, where <COUNTER> is incremented each time an instance of the same task is created. This way it is possible to figure out if any given task is an instance of another task by comparing the IDs before the '|' (pipe) symbol. The unique counter appended at the end allows the insertion of the same task in the activeTasks dictionary.

An "instances" data structure was added to keep track of the number of instances of a task.
Copy link
Member

@alexr00 alexr00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good PR! There are just a few changes before it can be merged.

@alexr00 alexr00 added this to the February 2020 milestone Feb 4, 2020
alpalla and others added 3 commits February 4, 2020 21:48
…er private because they only serve to maintain state and shouldn't be modified outside the class. Removed reveal and focus code in response to recent changes. Changed default RunOnOptions when reading from configuration for 'instances' attribute to value of 1.
Copy link
Member

@alexr00 alexr00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@alexr00 alexr00 merged commit e297e74 into microsoft:master Feb 5, 2020
@Gama11
Copy link
Contributor

Gama11 commented Feb 5, 2020

Will this be exposed in the Tasks API as well?

@alexr00
Copy link
Member

alexr00 commented Feb 5, 2020

Not at the moment. Do you want it in the tasks api?

@Gama11
Copy link
Contributor

Gama11 commented Feb 5, 2020

Yes, I have a use case for it. Though after rereading this, it seems like this only solves part of the issue, as you're still prompted each time you exceed the instance limit (so it sounds like #32264 shouldn't have been closed just yet while instancePolicy is still missing?).

In general, I don't see much of a reason to only expose some functionality of tasks.json to the Tasks API. It feels strange that the API would be less powerful than a JSON file (related: #73840). It might lead to extension authors being tempted to generate / modify tasks.json files again (which was a common workaround before the Tasks API existed).

@alexr00
Copy link
Member

alexr00 commented Feb 6, 2020

That's fair. I don't really want to expose every runOption in the API (in particular I don't want to expose runOn) but the instance properties could be useful. For instancePolicy I now have #90125 since I want to keep the original issue closed (that's how we know we need to test it).

@Gama11
Copy link
Contributor

Gama11 commented Feb 6, 2020

I could actually also see an extension wanting to contribute a task with "runOn": "folderOpen" . For instance In the Haxe extension that I help maintain, we need an initial compilation to build a cache for the language server. We implemented this inside of the language server, not using VSCode's tasks system at all, but it might make sense for something like that.

However, it could be argued that it's redundant since extensions can already do this in a more flexible manner via the runTask command, so yes, it's not much of a limitation to not have this particular option in the API.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants