Author bwhmather
Recipients asvetlov, bquinlan, bwhmather
Date 2015-09-21.11:04:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Sorry for slow response.  I completely missed your reply.

I was working on a project that used a concurrent.futures thread pool but also needed to listen to responses from a chip-and-pin card reader.

Payment sessions operated in three phases:
  - check with card reader that payment is possible
  - save payment to database as if it has happened (always best to undercharge in the case of an error)
  - ask the payment provider to commit the payment

Up until confirmation is received, it is entirely possible to cancel the session.
Once confirmation is received the session starts trying to commit and you can only really wait for it to finish and then roll back (or break everything).

This maps pretty well to the interface of future (though with very different plumbing and with work happening before cancellation stops working) and it made sense to try to write it so that it could interoperate with futures representing tasks running on the thread pool.

I tried to add a method which returned a plain concurrent.futures.Future object but couldn't find a way to hook into the cancel method without introducing loads of race conditions.

Really it just seemed wrong that I had an object that quacked like a duck but wasn't a duck because real ducks communicated over a hidden side channel.

The card reader library is open source and mostly functional.  The class is in:

I'm sure there are other places where this sort of interoperability would be useful.
Date User Action Args
2015-09-21 11:04:53bwhmathersetrecipients: + bwhmather, bquinlan, asvetlov
2015-09-21 11:04:53bwhmathersetmessageid: <>
2015-09-21 11:04:53bwhmatherlinkissue22729 messages
2015-09-21 11:04:52bwhmathercreate