Feature - Implemented Prevent multiple instances of kolmafia from accessing the same account

[MCroft]

We could try to release the lock just before we try to acquire it.

That’s where I wonder if we’d get into implementation-specific trouble because it’s advisory on macOS and enforced on Windows.

 

[MCroft]

And since ProcessManager came in with Java 9, I now know why it wasn’t done in 2007.

 

[fronobulax]

That’s where I wonder if we’d get into implementation-specific trouble because it’s advisory on macOS and enforced on Windows.

FileLock (Java Platform SE 7 )

"The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity."

Instances of KoLmafia cooperatively observe a known locking protocol. Is one of us reading this differently or are you concerned about non-mafia programs and I am not?

 

[heeheehee]

I don't think advisory locks are fundamentally problematic as long as all the consumers follow the same locking protocol.

Mac OS X Manual Page For flock(2)

HTML versions of the iOS man pages.

developer.apple.com

Advisory locks allow cooperating processes to perform consistent operations on files, but do not guarantee consistency (i.e., processes may still access files without using advisory locks possibly resulting in inconsistencies).

Either way -- https://github.com/kolmafia/kolmafia/pull/1479

 

[MCroft]

I am worried that if I stick releaseLock in acquireLock, it will delete a second instance’s lock file.

 

[fronobulax]

I am worried that if I stick releaseLock in acquireLock, it will delete a second instance’s lock file.

So you are deliberately designing an uncooperatively designed locking protocol? This is a theory discussion - if you are worried about something incorrectly implemented, OK, but a correct implementation is not supposed to be a problem. What am I missing that worries you?

 

[MCroft]

I’m worried that I’m accidentally designing a protocol that has a fatal flaw for a use case I haven’t really spent any time with.

But here’s the concern:
1: I start up instance 1, user 1. There is no user-1.active_file_lock. It is created.
2: I start up instance 2, user 1. The releaseLock is called. It deletes the lock file and creates one for instance_2.

That’s a stealable Lock, not an exclusive lock.

Maybe the releaseLock is smart enough not to release if it didn’t create it, but I want to test it. Especially if it thinks it has the lock and loses it to a timeout.

I could be all wet, but I am sorta concerned.

 

[MCroft]

Well, testing seems good so far:
1: started an instance at 9:20, put it to sleep.
2: returned to it at 9:36, it woke up fine.
3: started a 2nd instance, would not let me log in.
4: logged 2nd instance into a different character, worked fine, relay is distinct as desired (relay port may be a problem for "unlimited" instances
5: I am letting my main sit for a while to get that timeout to happen, but I am encouraged.

 

[heeheehee]

Hm. We should probably check for SESSION_HOLDER != null, not SESSION_FILE != null. But, given that SESSION_FILE.delete() is the last thing that releaseFileLock() does, it'll most likely just run into a NPE before it can do any harm...

 

[MCroft]

I tested everything I can without rollover and I didn't see a way to break it. I'll try to test it again tomorrow evening.

Thanks for working on this!

 

[MCroft]

let two sessions sleep through rollover.
session 2 successfully reconnected to user 2.
I logged out of user 2 and tried to log in to user 1.
I could not acquire a file lock (session 1 had it).
I opened session 1 and went to the relay browser. It re-logged in successfully.

I've worked through all the cases I know about.