felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Service Registry refactor using Java-5 concurrency libraries (Was Re: [Framework] ServiceRegistry.getService() endless loop with lock?)
Date Mon, 23 Mar 2015 14:17:00 GMT
On 23 March 2015 at 13:39, Richard S. Hall <heavy@ungoverned.org> wrote:
> 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.

I think that the Service Registry could be rewritten to be completely
free of synchronized blocks using the Java 5 concurrency libraries,
which I think would really be a better approach. There is too much
locking going on in the current SR implementation IMHO.

This brings the question: can we move to Java 5 (or Java 6) for the
Framework codebase? AFAIK we're currently still JDK 1.4 compatible but
I would be surprised if there is anyone who still needs a JDK that
went end-of-life 7 years ago.

Best regards,


View raw message