Follow-up Comment #3, patch #6353 (project duplicity):
> It looks to me like failures need to be handled properly
> (a try/finally around the asynch operation,
Backend failures are not currently handled, so this change should be ticketed
and patched separately.
> and some added book keeping to propagate the failure to
> the front-end thread waiting on the result).
Note that the busy spin in the lock wrapper is there to maintain the behavior
of exception handling.
> why not use some explicit state and a condition
> variable instead of the state being implicit in
> the lock acquisition/release?
This patch is intended to be small, easy to understand, and suitable for a
point release.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/patch/?6353>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
Duplicity-tracker mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/duplicity-tracker
