Community
Participate
Working Groups
The new discovery ui currently requires Java5 (because of generated EMF code as well as the new java.util.concurrent). This dependency should be reduced to Java 1.4.
Released the EMF change to HEAD (caused a couple of edit classes to move). However org.eclipse.ecf.discovery.model remains Java5 since the dependency towards java.util.concurrent.locks.Lock and java.util.concurrent.locks.ReentrantLock still exists. Though the current backport [1] works we need to file a CQ for it first. [1] http://backport-jsr166.sourceforge.net/
http://www.eclipse.org/newsportal/article.php?id=186&group=eclipse.tools.orbit#186
Released to HEAD
Created attachment 123070 [details] mylyn/context/zip
Scott Lewis wrote [1]: > Hi Markus, > > I saw that you added the emory backport of the concurrent API to the ECF > build and project set files. AFAICT, it seems to be for use in the > discovery ui ServiceResource class...i.e. it references the Lock and > ReentrantLock classes from the concurrent API (maybe others, but I > haven't found them). > > I haven't looked at this yet, but is it possible that this could use > some other mechanism?...e.g. the jobs API's ILock instead? It seems to > me like a lot of additional code, build/deploy difficulties, and > dependencies to just use a Lock class (even ReentrantLock). > > If we have to include it obviously we can (given the timely IP > approval)...but if we can avoid it that would be good also. > > Thanks, > > Scott > > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/runtime_jobs_locks.htm [1] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02027.html
Created attachment 123183 [details] org.eclipse.core.runtime.jobs.ILock instead of java.util.concurrent.Lock I agree that emory is a heavy weight dependency just to use one interface and a class. However, I am not entirely sure org.eclipse.core.runtime.jobs.ILock fits the requirements. org.eclipse.core.runtime.jobs.IJobManager.newLock() nowhere states that consumers get a fair [1] lock. Though the backing implementation org.eclipse.core.internal.jobs.OrderedLock appears to guarantee fairness, it's nothing to be certain of. And (correct) order of discovery events (discovery/undiscovery) is a must in org.eclipse.ecf.discovery.ui.model.resource.ServiceResource.ServiceDiscoveryListener. Anyway, here's a patch that uses org.eclipse.core.runtime.jobs.ILock instead. [1] http://osdir.com/ml/java.jsr.166-concurrency/2007-07/msg00027.html
(In reply to comment #6) > Created an attachment (id=123183) [details] > org.eclipse.core.runtime.jobs.ILock instead of java.util.concurrent.Lock > > I agree that emory is a heavy weight dependency just to use one interface and a > class. However, I am not entirely sure org.eclipse.core.runtime.jobs.ILock fits > the requirements. org.eclipse.core.runtime.jobs.IJobManager.newLock() nowhere > states that consumers get a fair [1] lock. Though the backing implementation > org.eclipse.core.internal.jobs.OrderedLock appears to guarantee fairness, it's > nothing to be certain of. And (correct) order of discovery events > (discovery/undiscovery) is a must in > org.eclipse.ecf.discovery.ui.model.resource.ServiceResource.ServiceDiscoveryListener. > > Anyway, here's a patch that uses org.eclipse.core.runtime.jobs.ILock instead. > > [1] http://osdir.com/ml/java.jsr.166-concurrency/2007-07/msg00027.html > Why don't you ask John A about the lock guarantees of OrderedLock? And if it doesn't fit/isn't enough then we can work out something else.
<rcjsuen> +yjob: <lemmy> Anybody else knows if JobManager.newLock guarantees to return a fair lock? <yjob> +From ILock class comment: Successive acquire attempts by different threads are queued and serviced on <yjob> + * a first come, first served basis. <yjob> +So "yes" <yjob> +ISchedulingRule isn't fair though <lemmy> yjob: so ILock is comparable to java.util.concurrent.ReentrantLock(true)? <yjob> lemmy: I guess so, with fair=true <yjob> ILock is implemented with a simple queue <yjob> I don't know how ReentrantLock is implemented, but I suspect it's similar
(In reply to comment #8) > <rcjsuen> +yjob: <lemmy> Anybody else knows if JobManager.newLock guarantees to > return a fair lock? > <yjob> +From ILock class comment: Successive acquire attempts by different > threads are queued and serviced on > <yjob> + * a first come, first served basis. > <yjob> +So "yes" > <yjob> +ISchedulingRule isn't fair though > <lemmy> yjob: so ILock is comparable to > java.util.concurrent.ReentrantLock(true)? > <yjob> lemmy: I guess so, with fair=true > <yjob> ILock is implemented with a simple queue > <yjob> I don't know how ReentrantLock is implemented, but I suspect it's > similar > So this sounds like ILock IJobManager.createLock() could probably be used?
Patch has been applied to HEAD. Emory dependency is gone and replaced by ILock.
Created attachment 123334 [details] mylyn/context/zip
