Before this changeset, async responses were:
- if not an error: ignored
- if an error: raised as response to the arbitrary/unrelated next command
Now, after sending async commands, the async_response command must be used
to process outstanding responses / exceptions.
We are avoiding to pile up lots of stuff in cases of high latency, because we do NOT
first wait until ALL responses have arrived, but we just can begin to process responses.
Calls with wait=False will just return what we already have received.
Repeated calls with wait=True until None is returned will fetch all responses.
Async commands now actually could have non-exception non-None results, but
this is not used yet. None responses are still dropped.
The motivation for this is to have a clear separation between a request
blowing up because it (itself) failed and failures unrelated to that request /
to that line in the sourcecode.
also: fix processing for async repo obj deletes
exception_ignored is a special object used that is "not None" (as None is used to signal
"finished with processing async results") but also not a potential async response result value.
Also:
added wait=True to chunk_decref() and add_chunk()
this makes async processing explicit - the default is synchronous and you only
need to be careful and do extra steps for async processing if you explicitly
request async by calling with wait=False (usually for speed reasons).
to process async results, use async_response, see above.
2**63 nanoseconds are 292 years, so this change is good until 2262.
See also https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2262
I expect that we will have plenty of time to revert this commit in time
for 2262.
timespec := time_t + long, so it's probably only 64 bits on some platforms
anyway.
Key type, location and manifest timestamp checks now survive cache
deletion. This also means that you can now delete your cache and avoid
previous warnings, since Borg can still tell it's safe.
If BORG_UNIQUE_HOSTNAME shell variable is set, stale locks
in both cache and repository are deleted.
Stale lock is defined as a lock that's originating from the same
hostname as us, and correspond to a pid that no longer exists.
This fixes#562
