Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] locking mechanism

See my comments below

From: Laurent Goubet <laurent.goubet@xxxxxxx>
Reply-To: "laurent.goubet@xxxxxxx" <laurent.goubet@xxxxxxx>
Date: Mittwoch, 18. Dezember 2013 10:52
To: EGit discussion <egit-dev@xxxxxxxxxxx>
Subject: [egit-dev] locking mechanism

Hi all,

I am not familiar with the locking mechanism that's been used in JGit, I think it is too limited, but I don't really know if it would be possible (and how) to make it a little friendlier. Consider the very simple test I attach to this mail (I had it as org.eclipse.egit.ui.test\src\org\eclipse\egit\ui\DeleteTest.java ... but its location is somewhat irrelevant).

The gist of it is : if I lock a repository's dir cache, I can no longer manipulate the workspace files supervised by it, even from sub-calls "under" my lock, but that's inconsistent :
DirCache dirCache = repo.lockDirCache();

IFile file1 = iProject.getFile(new Path("file1"));
file1.create(new ByteArrayInputStream(new byte[0]), false, new NullProgressMonitor()); // <- I can "create" a file just fine

file1.delete(false, new NullProgressMonitor()); // <- but tring to delete it fails miserably

dirCache.unlock();
I understand that what happens here is that EGit fails because of a workspace hook to automatically add "deleted" files to the index, but that hook cannot lock the index since I've already taken that lock beforehand.

My questions would be :

- Why are we only "automatically adding to the index" when the user deletes files, but not when he adds some? I think that if we do one, we should do the other. Not to mention that here, the hook fails to automatically stage the deletion of a file which creation had yet to be staged (i.e. a no-op).

 I also don't understand why deletions are automatically added to the index. Maybe this was necessary at the very beginning of the Egit/Jgit project. I would rather remove it for the deletion of files than add it for adding files.


- Since I call "delete" in a place where I _do_ hold the DirCache's lock, should this really fail? There should be a way for the delete hook to get a hold of the lock its thread holds, but how could I go about making this lock thread local?

I think the intention of the DirCache's lock is to use it on low-level operations on the git index. In that case it should not happen that another code is called which also wants to lock the DirCache. So what is the use-case for locking the DirCache and inside the lock calling an operation on an Eclipse-Resource?

Back to the top