[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Equinox lazy bundle start and deadlocks

I'm not sure why you cannot just activate every bundle at launch if you don't care about lazy activation. Is that what you tried to do but it failed?

A testcase would really help here. You mention lots of locks below but I'm not sure if these are class loader locks established by the vm or framework locks associated with Bundle lifecycles or DS impl locks. I suggest you open a bug against Equinox->Framework to track dead lock issues you are seeing with lazy activation.

If class loading locks are causing the issue then I suspect you are running into a flavor of https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737. Locking the class loader at the VM level is blocked by a long standing Sun http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071. It would be interesting to know if the VM args mentioned at https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737#c8 help solve your problem.

Tom



Inactive hide details for "Jan Stette" ---05/21/2008 08:09:54 AM---I'm running with a fairly recent version of the ProSyst DS. "Jan Stette" ---05/21/2008 08:09:54 AM---I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs y


From:

"Jan Stette" <jan.stette@xxxxxxxxx>

To:

"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>

Date:

05/21/2008 08:09 AM

Subject:

Re: [equinox-dev] Equinox lazy bundle start and deadlocks




I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs you mention though (we saw those earlier before we got patches for those). Specifically, those bugs don't involve lazy bundle starting.

It seems to me that there's an inherent problem with the lazy bundle starting. What we're seeing is that one thread goes through the steps:

Bundle is activated -> DS is notified, gets lock -> enters class loader as part of activating a service, gets lock.

Whereas a second thread does:

Enters class loader, gets lock -> bundle is lazily loaded -> DS is notified, gets lock.

So in one thread, a lock in DS is held before the classloader lock is acquired, in the other thread the classloader lock is held then it calls out to DS which will acquire a lock.

Maybe it would be possible to work around this specific case by juggling locks inside the DS implementation. But it just seems to me that it would be very difficult to guard against future errors along this line. Basically, the lazy bundle loading means that any innocent-looking line of code like:

Widget = new Widget();

anywhere in my code can cause a very long chain of synchronous events including calling back out to my code through bundle and service listener interfaces. Ensuring that locking is correct in all situations seems completely impossible, so I'd much rather just turn lazy loading off. Any suggestions for what is the best way to do this?

Regards,
Jan






2008/5/21 Thomas Watson <tjwatson@xxxxxxxxxx>:

From:

"Jan Stette" <jan.stette@xxxxxxxxx>

To:

"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>

Date:

05/21/2008 07:19 AM

Subject:

[equinox-dev] Equinox lazy bundle start and deadlocks
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

GIF image

GIF image

GIF image