fix: attempt to only allow one deno process to update the node_modules folder at a time #18058
Conversation
| @@ -255,17 +277,25 @@ impl ProgressBar { | |||
| } | |||
|
|
|||
| pub fn update(&self, msg: &str) -> UpdateGuard { | |||
| self.update_with_prompt(ProgressMessagePrompt::Download, msg) | |||
| } | |||
There was a problem hiding this comment.
I could have spent some time making our progress bars more general use, but I didn't think it was worth the time atm.
There was a problem hiding this comment.
As I side note: we should lazily create ProgressBar on ProcState - it currently shows up in the flamegraphs for each startup when it's checking if we can actually draw. (even if we never use the progress bar, like when only loading local files)
There was a problem hiding this comment.
I'll lazily create it here
There was a problem hiding this comment.
Oh wait, not worth it because IS_TTY_WITH_CONSOLE_SIZE is already in a lazy and it would have hit that by now.
Edit: Meh, I'll just lazily create it anyway.
| // Spawn a blocking task that will continually update a file | ||
| // signalling the lock is alive. This is a fail safe for when | ||
| // a file lock is never released. For example, on some operating | ||
| // systems, if a process does not release the lock (say it's | ||
| // killed), then the OS may release it at an indeterminate time | ||
| // | ||
| // This uses a blocking task because we use a single threaded | ||
| // runtime and this is time sensitive so we don't want it to update | ||
| // at the whims of of whatever is occurring on the runtime thread. | ||
| tokio::task::spawn_blocking({ |
There was a problem hiding this comment.
Cool 👍 I was worried about this scenario, but you handled it nicely.
| @@ -255,17 +277,25 @@ impl ProgressBar { | |||
| } | |||
|
|
|||
| pub fn update(&self, msg: &str) -> UpdateGuard { | |||
| self.update_with_prompt(ProgressMessagePrompt::Download, msg) | |||
| } | |||
There was a problem hiding this comment.
As I side note: we should lazily create ProgressBar on ProcState - it currently shows up in the flamegraphs for each startup when it's checking if we can actually draw. (even if we never use the progress bar, like when only loading local files)
With an artificial delay:
2023-03-07_19-47-16.mp4
This is implemented in such a way that it should still allow processes to go through when a file lock wasn't properly cleaned up and the OS hasn't released it yet (but with a 200ms-ish delay).
Closes #18039