[WIP] Cache repository / owner values in persistent handle#962
[WIP] Cache repository / owner values in persistent handle#962srajko wants to merge 3 commits intonodegit:masterfrom
Conversation
ef7992d to
36d6a31
Compare
|
@srajko seems like it's dying on https://travis-ci.org/nodegit/nodegit/jobs/118155322#L6162-L6163 |
|
Same on appveyor |
|
Looks like it's creating a wrapper around a NULL raw value (a null tree in this case), and crashing trying to get NULL's owner. I can put a check around it. |
36d6a31 to
6cc808e
Compare
|
That took care of the hangs. There is consistent failure now with one of the submodule tests, but that's because it's using the defective repo. Switching to a different one should help. |
|
Actually, no - it looks like it might be a problem with taking the result of |
|
I fixed the test to pass the ID since NodeGit is expecting an ID there. Briefly looked at the behavior on |
Affects: git_blob_owner git_commit_owner git_filter_source_repo git_index_owner git_object_owner git_reference_owner git_remote_owner git_revwalk_repository git_submodule_owner git_tag_owner git_tree_owner
2523569 to
cd21a0f
Compare
a78275a to
206d27d
Compare
|
I've completed this in master. |
This works towards #955. Once we free repositories on wrapper GC, any object that can return a repository (for example, a
GitCommit) can potentially return a freed repository. This PR adds persistent handles to any object that returns a repository. Once we enforce a 1-1 relationship betweengit_repositoryobjects andGitRepositorywrappers, this will ensure that the wrapper does not get GCd until all objects that can return the repository can get GCed as well.The stand-alone benefit of this PR is just that we don't create a new wrapper each time we return a repository from an object.
Also, the caching mechanism might be helpful beyond holding a handle - we can extend it to cache any similar value and avoid calling into the libgit2 layer for sync functions (this can help with thread safety without requiring locking).