We must FIGHT to the end.

I don't understand though... Are they really the same thing?

I believe so... Both expose a promise that can be resolved from the outside Barrier#open vs PromiseSource#complete.

I prefer to keep Barrier, because I like to think of it as a separate synchronization mechanism than promises, even if it uses promises as its implementation.

So, I would live with the "duplication".

Well, the single usage of the PromiseSource seems like a good usage for Barrier because it seems to synchronise on the shared process startup/spawning

👍 To replace the usage of PromiseSource with Barrier in SharedProcess.

@joaomoreno It does look like you have a barrier type of usage going on in the SharedProcess class. The only implementation diff I can spot is that the PromiseSource can be canceled, but that might be an implementation mistake. The PromiseSource can also be errored, but that appears to be not used.

Well, there is a wait() method which returns a Promise... so Promises don't seem to be just an implementation detail. Also, I don't think the word Barrier conveys the right meaning to the functionality it provides.

But sure. All for the glory of less code. I had to move it down, so I just replaced PromiseSource with it in vs/base/common/async.