On Mon, Jan 24, 2011 at 09:49, Sahoo <[email protected]> wrote: > wait(0) causes a thread to wait until notified or interrupted, so why > why should any CPU cycles be wasted?
You're right, forget about that. > Secondly, can you also tell me why > you think it is artificial? Can't the instructions be reordered such > that the watcher threads start before initialization is complete? Everything comes down to the fact that the ConfigAdmin support is started before the other trackers are created and opened IIUC, so on the JIRA issue, I suggested to simply move that part to the end of the initialization, so that no DirectoryWatcher threads can be started before everything is set up. I think that would solve the problem in a cleaner way. > > Sahoo > > On Monday 24 January 2011 12:54 PM, Guillaume Nodet wrote: >> I don't really like this solution of introducing an artifical and >> unneeded lock, as reordering the initialization in the activator >> should work better imho. >> >> Anyway, wouldn't the loop with wait(0) spin the CPU at 100% in case we >> hit this issue ? >> >> On Thu, Jan 20, 2011 at 14:06, Sahoo<[email protected]> wrote: >> >>> Hi, >>> >>> We solved 1 issue in this release: >>> >>> ** Bug >>> * [FELIX-2791] - NPE in getStartLevel due to race condition >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-057/ >>> >>> You can use this UNIX script to download the release and verify the >>> signatures: >>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>> >>> Usage: >>> sh check_staged_release.sh 057 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> This vote will be open for 72 hours. >>> >>> Thanks, >>> Sahoo >>> >>> >> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
