mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

thoughts

Browse source
This commit is contained in:
Joey Hess 2018-04-03 15:31:08 -04:00
parent 786c7cc06a
commit c4f034e6b3
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 30 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_5_098b2e2c51f70d495fe1587220173f55._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2018-04-03T19:17:32Z"
content="""
PREPARE-FAILURE is documented as "the special remote cannot be used"
and so I don't think it makes sense for git-annex to use the previously
started instance of the program if a later one fails like that.
It would need a new response to PREPARE. And some possibly not
insignificant changes in Remote/External.hs to support it. In particular,
Remote/External.hs currently delays sending PREPARE until the first time
it uses a special remote, but this seems to need PREPARE to be sent
earlier, when it starts up the special remote, so it can detect the new
response and remember that it should not try to start up any more
concurrent instances and instead use any already started instance.
The best argument for doing it, I think, is if several different external
special remote programs really only support a single instance running at a
time, and if supporting that inside git-annex would be enough of a win,
rather than making those programs do their own locking.
Hmm, an external special remote program can't just block its response to
PREPARE when another instance is running, because it would never be able to
un-block. So it seems they would have to use finer-grained locking when
responding to eg TRANSFER. I don't know if anything other than datalad
needs such locking (and IIUC datalad already got the necessary locking),
but it does seem like it would be worth adding an extra PREPARE response
to avoid needing to so complicate external special remote programs.
"""]]