On Wed, Apr 28, 2021 at 11:00 AM Jörg Kubitz <jkubitz-ecli...@gmx.de> wrote:
> is there any documentation how/if files in the workspace can be written > in parallel? > There is a bit of it in http://www.eclipse.org/articles/Article-Concurrency/jobs-api.html > Are there junit tests for concurrenct workspace modifications? > Yes, probably. However I'm not aware of what tests do take care of that particularly. Tests in eclipse.platform.resources/tests/org.eclipse.core.tests.resources should be audited to find out which one deal with concurrency/scheduling rules. If that locking is removed or only held on a part of the workspace (as > suggested by Mickael mistria) i still see sourcecode which does not seem > to be thread safe. Locking should really not be removed by default, at all. However, the current model of locking a whole subtree and not being able to release subtrees of this subtrees is a bit too restricted; and the fact that rules are only compoundable according to inclusions is also too limited. It's more the duty of individual workspace manipulations to optimize their usage of the workspace to either 1. lock a subtree if they really need it and 2. avoid locking more than the strict minimal necessary things. > For example usage of AliasManager.aliases in AliasManager.updateAliases() > I did not see any actual error happening there i just wondering if that is > a) not meant to be used in parallel > b) has some magic synchronization which i dont see > c) is an error which just have such a small chance to happen that it > does normally not happen. > It could be a bit of all ;) Can you please elaborate about a concrete case you think can be faulty with current code? Ideally in a test case you could submit through Gerrit?
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
