@mw Is there some particular reason we run
finalize_session_directory after linking?
One reason could be that we don't want the directory to be finalized if there are any linking errors
but I don't know if that is even validated properly at the moment
other than that I think the session directory will only contain pre-linking artifacts
at least as long as we don't do any incremental linking
but the main reason it's done this way is probably that it was a safe choice and there was no reason to do it earlier at the time
I made it run in parallel with linking, let's see if any errors pop up.
that's probably fine
how much work is being done in
finalize_session_directory these days? If it is just renaming the directory, then it probably doesn't matter
Takes 0.3 seconds for syntex_syntax
that might be the call to
we should certainly keep this change in mind if any bug reports come in
these filesystem operations often cause hard to reproduce bugs and behavior can vary quite a bit between platforms, filesystems, OS versions, etc.
I've taken a look at
finalize_session_directory and it does read
sess.has_errors_or_delayed_span_bugs(). If anything in linking can change that value then I am against doing the two things in parallel, since the finalization outcome would depend on a race.
We can just read that before spawning it off
I wonder if there is a way to make this safe. E.g. by making sure that linking and finalization don't access shared mutable state (like the session directory).
I did notice that something still accessed the session directory while linking, not sure what though.