Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Revisit introduction of `mainLockfile`

See original GitHub issue

It looks like recently a mainLockfile was added to signal whether a user data dir is in use or not (https://github.com/microsoft/vscode/commit/126218be8798646ca3b36dd13d4702a380d98b3f). I see numerous issues with that:

writing a file on startup slows down startup, especially if the process has to wait for that to happen. We typically only tolerate this when there is very strong need for it and try to avoid this at all costs (cc @jrieken). It seems here we only add the log file for the debug case for debugging VSCode, but every user now will pay the price of slower startup even when not debugging VSCode.
dealing with files as a means to lock a folder is complicated. you cannot assume that lifecycleMainService.onWillShutdown is ever called, the application might crash leaving a stale lock file around (cc @alexdima who just implemented a locking solution that avoids these kind of issues for the extension host state process via https://github.com/microsoft/vscode/commit/b1b44a3910c7df865eea155c3c367c2ec085b2bd)

I don’t really understand why the existing IPC socket cannot be used to figure out if an instance is running? The IPC handle is statically computed based on some properties that can all be determined by reading package.json and or product.json:

https://github.com/microsoft/vscode/blob/126218be8798646ca3b36dd13d4702a380d98b3f/src/vs/platform/environment/electron-main/environmentMainService.ts#L54-L54

I hope we can find a different solution for this.