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

[Andrew Su]

----- 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))?

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.

> 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