[icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true

[Denis Lila]

> Denis brought this up too. Maybe I am missing something -- even if CHM
> does its own locking, wouldn't the caller thread still own the
> monitor,
> thus making it a non-issue? We'd just be locking it earlier. If
> outside
> locking is a concern, that would make CHM very dangerous to use in any
> sort of multi-threaded environment that might lock it before an op.

Whenever an object L does it's own locking, there's a deadlock
possibility if we have code like this:

synchronized(L) {
  synchronized(Other) {
    code;
  }
}

synchronized(Other) {
  L.anyMethod();
}

And combing through code trying to find this pattern would be very
annoying.
For us, that's not a problem (yet). My concern when I brought this up
was one of increased contention, but thinking about it more, it
didn't make much sense, so I won't mention it.

I really don't think we should go back to HMs though. If we did that
we'd have to lock on every get.

Regards,
Denis.

----- Original Message -----
> * Dr Andrew John Hughes <ahughes at redhat.com> [2011-04-14 16:32]:
> > On 09:22 Thu 14 Apr , Deepak Bhole wrote:
> > > * Dr Andrew John Hughes <ahughes at redhat.com> [2011-04-14 07:41]:
> > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote:
> > > > > * Deepak Bhole <dbhole at redhat.com> [2011-04-13 20:48]:
> > > > > > Hi,
> > > > > >
> > > > > > Andrew mentioned in one of the previous threads that the
> > > > > > current plugin
...