This message was deleted.

The synchronization code makes sure that languageRuntimeServer.Run calls execute serially. It's possible that the engine could try to initiate more than one of these, and we want to prevent concurrent updates (or unnecessary failures due to conflicts). The flow is that automation api creates an instance of

languageRuntimeServer

and passes its address to the engine via the CLI. The server waits for the engine to call the Run gRPC method. The server has a lock to make sure that the engine doesn't try to start two concurrent updates on the server (could be a retry, guarding against future implementation changes).

Right, but it seems like it is possible to have two concurrent updates with the current code:

Thread A enters

Run()

Thread A gets the lock, sets the state from

waiting

to

running

, and releases the lock

Thread A calls

RunWithContext()

Thread B enters

Run()

Thread B gets the lock, sets the state from

running

to

running

, and releases the lock

Thread B calls

RunWithContext()

// Current updates!

Thread A gets the lock, sets the state from

running

to

finished

, and releases the lock

Thread B gets the lock, sets the state from

finished

to

finished

, and releases the lock

Ahh, good catch 🙂