Unlock configuration file during download

[LilithHafner]

When I run juliaup add 1.7 it takes a long time to download because of a slow internet connection. This is okay, but when I try to launch julia +1.8.2 in a different terminal, I get "Juliaup configuration is locked by another process, waiting for it to unlock." It would be nice to unlock the configuration during the download process and only lock it very briefly when doing actual work with the configuration.

[StefanKarpinski]

Might also be possible to do more granular read/write locking: many read locks can co-exist and they only conflict with a write lock, which is exclusive. I have no idea if Rust supports that, but if it does that would be ideal. If the operations expect the configuration not to change while they're doing their thing, that might be a better approach than making the lock region smaller.

[davidanthoff]

The design at the moment is using one global read-write lock, so things only ever block if an operation that changes things is acquiring the write lock. Essentially what @StefanKarpinski described.

The issue here is that the steps are essentially:

1. Read the config file (so that requires taking the lock, and at the moment it acquires the write lock)
2. Download and extract new version
3. Add the new version to the config file
4. Release the lock

A better implementation would be to

1. Acquire read lock and read the config file, then immediately release the lock. Store the content of the config file in memory.
2. Download the new version.
3. Acquire the write lock, check whether the config file has changed relative to the version that was stored in memory in step 1. If it was changed, abort.
4. Put the new stuff into the correct location and update the config file.
5. Release the write lock.

All pretty doable, I'd say. The only thing that really needs to change is probably that right now I'm downloading the file and then extract everything directly into the target directory, so splitting "download and extract" up into two steps with a lock acquire in between needs some extra work. The solution I think is to download and extract into a temporary folder, and then step 4 in the new model would just be a directory move operation. That would be a better way to do things in any case, irrespective of the locking strategy.

[LilithHafner]

Agreed, however, in step three, instead of checking for any change I'd check to see if a new installation is still warranted (same check that is performed in step 1 to decide whether to tell the user "Already up to date"). That way it is possible to install multiple different versions in parallel and requires less memory (the former is substantive, the latter is not)

[davidanthoff]

Yes, that would be even better!

[evetion]

Relates to #561

[davidanthoff]

I'm working on this one right now.

[LilithHafner]

Thanks! Feel free to @ me when you make a PR, I'd love to see it.

[gaurav-arya]

I'm hitting the same error doing when trying to install juliaup because of my cluster disallows lock in the home directory, e.g. here is the FAQ entry describing the behaviour in a different context:

[davidanthoff]

@gaurav-arya the issue you are describing is not related to the topic of this issue here, the problem you have is tracked in #561.