API Suggestions Discussion: locks for run_command

[FichteFoll]

Continuing the discussion from API Suggestions:

API Suggestions

Introduce new optional parameter in run_command() method:

def run_command(command_name, cmd_params, lock=None)):

It would be wonderful if commands executed witch run_command could be synchronized by use of threading.Lock.

This proposal makes no sense. Commands are always run synchronously. If they do actions in an asynchronous way, ST wouldn’t be able to recognize this anyway and it’s the plugin’s job to properly synchronize its actions.

[BPS]

I’ve made error in my suggestion, sorry about that. What I really wanted to say is:

it would be nice if ‘exec’ command had new setting which allows to set lock for synchronizing jobs performed on same set of files.

Consider example case:
I have 3 commands ‘exec’ executed in row, each command is same executable but executed with different parameters, each command modifies my project files:

my_lock = threading.Lock()

self.window.run_command('exec', {
    'cmd': ('do_long_file_operation', param_a), 
    'lock': my_lock
})
self.window.run_command('exec', {
    'cmd': ('do_long_file_operation', param_b),
    'lock': my_lock
})
self.window.run_command('exec', {
    'cmd': ('do_long_file_operation', param_c),
    'lock': my_lock
})

In this situation lock would prevent changing my files in bad order and damaging them in process.

[FichteFoll]

Unless you want the user to see the output of the external operation, you should be directly invoking subprocess.Popen here.