[RFC][Icedtea-Web]: Fix bug where you can clear cache while plugin is in use.

[Denis Lila]

> Yes your suggestion would solve the problem about the order which
> clearcache and marking is called. We were talking about different
> things, I was talking about running more than one javaws/plugin in an
> environment that only gives exclusive locks.

So was I. There was a misunderstanding here. Andrew found a problem
with my proposed 2 lock solution and we found a better one on irc.
For the record, here's the log:

<denis> asu_wfh: you said "We were talking about different things, I was talking about running more than one javaws/plugin in an environment that only gives exclusive locks."
<asu_wfh> denis: haha yeah
<denis> asu_wfh: when I suggested the thing with 2 locks
<denis> asu_wfh: that's what I was trying to solve
<asu_wfh> oh what? the exclusive lock issue?
<denis> asu_wfh: yeah
<asu_wfh> I don't see that working for that
<denis> asu_wfh: ah, nice. Why?
<asu_wfh> the plugin won't continue but it will just hang there until the other one terminates
<denis> asu_wfh: which other one?
<asu_wfh> I don't think having it hang is good, the other plugin might not terminate anytime soon
<asu_wfh> ok say you have plugin 1 and 2
<denis> asu_wfh: but how does it hang?
<denis> I don't see
<asu_wfh> denis: in marknetxrunning trylock fails, so it goes on to block on CL
<asu_wfh> ok we are talking about different thing.
<denis> asu_wfh: yeah, we are
<denis> asu_wfh: it does block on CL
<denis> asu_wfh: but it immediately releases it
<denis> tryLock(KEY_USER_NETX_RUNNING_FILE) // already do this
<denis> lock(CL) // this blocks
<denis> release(CL)
<denis> asu_wfh: so, it only blocks if there's a "clear cache" call going on
<asu_wfh> denis: are you talking about the relationship between clearing cache and plugin?
<denis> in which case, we want it to block
<denis> asu_wfh: no, I'm just talking about multiple javaws running concurrently 
<denis> asu_wfh: so, if there is no "clear cache" in progress, we just do "tryLock(RUNNING_FILE)", which doesn't block
<denis> asu_wfh: and then we do lock(CL), which does block, but it should only be for a very short period
<denis> asu_wfh: because every other case where we lock(CL) releases the lock immediately
<asu_wfh> ok but how does that allow us to run multiple javaws?
<denis> asu_wfh: well, let's say we have to instances A, B
<denis> A locks CL, and B also tries to lock it
<denis> B blocks
<denis> then A releases it immediately, so B gets it and also releases it
<denis> so then they both run normally
<asu_wfh> the thing is trylock in B will fail
<denis> asu_wfh: yeah, but it's ok. We just ignore that
<denis> just like we do now
<asu_wfh> that's not good
<denis> asu_wfh: why not?
<asu_wfh> I don't want it to fail, that needs to be changed
<asu_wfh> ok A gets lock from tryLock, B fails but continues, A finishes and terminates (lock released), C tries to clear cache (succeeds becasue there is nothing holding lock)
<asu_wfh> now B errors because the jars are missing
<denis> asu_wfh: hm, I see
<asu_wfh> If it fails to get a lock it should block
<asu_wfh> but
<asu_wfh> we don't want it to really block that's why we have shared locks
<denis> yeah, then we can only run one thing at a time
<asu_wfh> so the problem is the exclusive locks on systems that don't support it =(
<denis> asu_wfh: how about this: we make each javaws take a lock only for a small region
<denis> asu_wfh: so, A locks region (0, 1), B locks (1, 2)
<denis> asu_wfh: and in clear cache, we try to lock region (0, Long.Max_value)
<denis> asu_wfh: that way clear cache will still not proceed if anything is running, and all javaws processes will still be able to take a lock, even if there are no shared locks
<asu_wfh> denis: yes that works (theoretically) Just don't like idea about going through 1 to long.max_value to find an empty spot
<denis> asu_wfh: well, we'll only have to go up to the number of concurrently running instances
<asu_wfh> denis: yeah i know
<denis> asu_wfh: or a little bit higher, which won't be much larger than 20, I would guess
<asu_wfh> denis: I doubt you could get that many process running without lag anyways long.max_value's pretting...long lol
<denis> asu_wfh: I agree that it's not a perfect solution (I think there's a race condition in there somewhere), but it's only a backup plan if a system doesn't have shared locks
<denis> asu_wfh: actually, I found a way of removing the race condition when searching for a region to lockon
<asu_wfh> I don't see the race condition on this
<denis> asu_wfh: I thought we might have a problem where two processes compete for a lock, and neither gets it and just keep trying to get locks on higher regions, leaving lower ones unused
<denis> asu_wfh: but you're right, it's not a problem 
<denis> even better :D

Regards,
Denis.

----- Original Message -----
> ----- Original Message -----
> > > It does get called every time it is about to launch an
> > > applet/application.
> >
> > Yeah, that's what I meant when I said it's called rarely -
> > markRunning will be called once per applet, and the number
> > of function calls in any one applet will vastly outnumber
> > the number of applet creations. Still, it's a good idea
> > to return early on null.
> 
> yup.
> 
> >
> > > Ah yes, I missed that. It is ok if we don't release the lock from
> > > okToClearCache since these calls should only happen when either
> > > the
> > > jvm is shuttingdown or when we call to clear cache which will
> > > return
> > > after it does its check + clear if allowed.
> >
> > Just to make sure we're on the same page: do we agree that the lock
> > should be released only after the cache is actually cleared?
> 
> We don't need to specifically release it after clearing cache, since
> javaws will terminate and the locks will be freed.
> 
> >
> >
> > > In the event that we can only get exclusive locks, this means we
> > > can
> > > only have 1 plugin, or 1 javaws running at a time.
> >
> > That's right. Isn't that a huge problem?
> >
> > > This can be solved by having essentially a semaphore kind of
> > > structure. (Don't like this...JVM can be killed via kill -9 and it
> > > won't decrement the count).
> > > Another way to do this is give them all their own unique cache
> > > directory, no more worries...But this defeats the purpose of a
> > > cache..
> >
> > What about what I suggested (with the two locks (actually, we could
> > just
> > use locks on disjoint regions of the same file - we don't have to
> > introduce a new file))?
> 
> 
> > Then again, this problem only needs to be solved if the platform
> > we're
> > running on doesn't support shared locks. If they all do support
> > shared
> > locks, then we can just replace tryLock with lock in mark_running
> > and forget about these complicated solutions.
> 
> Agreed. Anyone have a suggestion for this?
> 
> Cheers,
> Andrew