On Mon, Jan 24, 2011 at 13:54, Sahoo <[email protected]> wrote: > On Monday 24 January 2011 02:34 PM, Guillaume Nodet wrote: >> >> 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. >> >> > > We can't rely on program order being same as the execution order in a > multi-threaded environment, can we? So, an explicit barrier is a much better > way to guarantee that watcher threads don't run before initialization of > fileinstall is complete. >
In that case, the activator is called and watcher threads are only created (indirectly) because it registers the ConfigAdmin ManagedService in the OSGi registry, so until the activator does so, there is only a single thread running. It would have been sufficient to just make sure everything is initialized before starting spawning threads (by registering the CM support of calling update(xxx) Anyway that's really not big of a deal. FWIW, I have another bug fix i really need which is FELIX-2798 so in all cases, I'll recut a 3.1.8 release this week (unless that one is cancelled for whatever reason). > Sahoo > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
