On 06/18/2015 02:25 PM, John Arthorne wrote:
Hi Mickael,
Take a look at the Javadoc for Job#join methods, they describe in
detail why this is not permitted. Essentially it is a high deadlock
risk when combined with job pool throttling.
Thanks, I didn't look in the Javadoc, which contains a good explanation.
I'd advocate that a deadlock is always possible with a join in any case,
and that I don't think the API has to be so limiting.
Actually, I anticipated this potential deadlock issue because of missing
threads for the group in the code and used some guards to avoid deadlocks.
if (jobGroup.getMaxThreads() == 0 || jobGroup.getActiveJobs().size()
< jobGroup getMaxThreads()) {
crawlerJob.setJobGroup(jobGroup);
crawlerJob.schedule();
} else {
crawlerJob.run(); // run in current thread to avoid deadlock
waiting for a new thread
}
Also, I am 100% sure that as long as I have more threads than the
"depth" of the folder it crawls, there will be no deadlock.
In such condition where the developer has some assumption about the
ability to safely throttle and call join in a job group, is there a way
to bypass this check?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev
