Download / Unpacking triggers on several atom windows after update

[pelallemant]

Hi,

I always opened alot of atom windows, I just updated ide-php and atom-ide-ui. I think the "problem" is related to ide-php.

In the bottom-right corner, after updating there is a loading spinner about "downloading / unpacking", I suppose this is the php-languageserver which is downloaded by ide-php.

If you open another atom window before the archive is installed, the 2nd atom will fetch/unpack the package too.

I suggest to add a semaphore/mutex (file semaphore I'd say, since variable can't be shared between processes) in order that only one of the atom windows will be able to download the package.

It doesn't seem to have caused a bug to my installation, the package seems to work well.

[damieng]

Nice find, I'm still thinking about how to achieve this reliably. We can't lock a file due to cross-platform compatibility and if we write a semaphore file to disk to indicate to the other windows it is in progress then they'll have no progress indicator plus if you close the one doing the actual downloading...

Ideas welcome :)

[pelallemant]

I already wrote such a system for other purposes, it is a bit horrible but can be resumed like this.

• the process looks at LOCK_FILE existance to see if it is locked
• if LOCK_FILE doesn't exists, he write a LOCK_FILE with the current date in ms, and the process pid. We can suppose 2 atom windows could write at the same time. This step is the "LOCK_ATTEMPT" step
• if LOCK_FILE exists, if the date > 2s from now, then process as if the LOCK_FILE wasn't present. ie launch a LOCK_ATTEMPT.
• the processes which performed a LOCK_ATTEMPT wait 50/100ms, at the moment they create the file. If the pid in it is their own pid, then it considers it is locked. It means it is not always the 1st window to write the file which will have the lock.

I could try to make a github repository of this system, I had to imaginate & write it for another purpose, but it seems it could fit there.

[damieng]

I think we might want to actually do some kind of status file with similar semantics that the primary process can write the current status bar text to... and the other processes can read and display it. That way they all get the same download/unpacking etc.