On 3/23/15 03:55 , Guillaume Nodet wrote:
There's a call to interrupt() in Felix#acquireBundleLock(), not sure if it
can be the culprit though.
Interrupts could also be caused by a bundle being shutdown while one of its
thread is waiting for a service, which should is a valid use case imho.
Anyway, I think sanely reacting to a thread being interrupted would be good.
Yes, threads can be interrupted if they are holding a bundle lock and
the global lock holder needs the bundle lock.
I admit that I do not recall why we ignore the interrupt here, but
didn't we implement service lookup so that a bundle lock wasn't
necessary? I thought we just checked for the validity of the bundle
context before returning or something. Perhaps we felt there was no
reason to be interrupted in that case. I really don't know.
-> richard
2015-03-23 8:46 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>:
Am 23.03.15 um 01:25 schrieb Richard S. Hall:
On 3/21/15 05:52 , Carsten Ziegeler wrote:
Question remains, why the thread got interrupted in the first place.
It was something that you did as part of FELIX-4806:
Yes, I noticed this as well - and I have no idea why I did it. I know
that I worked on some other code at that time where it was good to add
the interrupt call. Maybe a case of repeating the pattern :(
But my question was not why this piece of code has been added but
rather why the thread gets interrupted in the first place.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
