You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.
This would allow cancellation without breaking API compatibility.
Internally, the implementation could (for example) check for context cancellation before/after each file is written (or read) to/from an archive and abort if the context is cancelled.
Why is this feature a useful, necessary, and/or important addition to this project?
Archiving/unarchiving in particular can be long-running operations. It would be useful to allow a cancellation/timeout mechanism for callers.
What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?
There is no alternative currently, other than performing the long-running operation in a separate goroutine and then ignoring or throwing away the results if the caller cancelled and is no longer interested.
The text was updated successfully, but these errors were encountered:
Yeah, this would be good in a v4 rewrite. I would rather do that, considering all the open issues, than litter the API with a bunch of Context alternatives.
What would you like to have changed?
Consider adding
...WithContext()
functions/methods for long-running operations to allow cancellation by callers.Example:
ArchiveWithContext(ctx context.Context, sources []string, destination string) error
This would allow cancellation without breaking API compatibility.
Internally, the implementation could (for example) check for context cancellation before/after each file is written (or read) to/from an archive and abort if the context is cancelled.
Why is this feature a useful, necessary, and/or important addition to this project?
Archiving/unarchiving in particular can be long-running operations. It would be useful to allow a cancellation/timeout mechanism for callers.
What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?
There is no alternative currently, other than performing the long-running operation in a separate goroutine and then ignoring or throwing away the results if the caller cancelled and is no longer interested.
The text was updated successfully, but these errors were encountered: