Author serhiy.storchaka
Recipients carlorosati, davin, hongweipeng, josh.r, rhettinger, serhiy.storchaka, xiang.zhang, xtreak
Date 2019-08-22.06:45:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1566456318.98.0.349976175008.issue34410@roundup.psfhosted.org>
In-reply-to
Content
I tried to solve this issue myself, and figured out that it is not so simple. It is possible to make tee() nor crashing, but it is not possible to guarantee the order of the output without using a lock in tee(). It you can get a sequence 1, 2, 4, 3, ...

So we have the following options:

1. Document that the tee() iterator can not be consumed from different threads, even if an underlying iterator is thread-safe.
2. Detect the race condition and raise a RuntimeError (as for iterating modifying dicts).
3. Fix a crash, but document that the tee() iterator can return items out of order if consumed from different threads (PR 9254 basically does this). And exceptions can be raised out of order too.
4. Add a non-reentrant lock in the tee() object and raise a RuntimeError if it is re-entered.
5. Add a reentrant lock in the tee() object.

We can apply different solutions in developed and maintained versions. I would not backport options with locks.
History
Date User Action Args
2019-08-22 06:45:19serhiy.storchakasetrecipients: + serhiy.storchaka, rhettinger, josh.r, davin, xiang.zhang, hongweipeng, xtreak, carlorosati
2019-08-22 06:45:18serhiy.storchakasetmessageid: <1566456318.98.0.349976175008.issue34410@roundup.psfhosted.org>
2019-08-22 06:45:18serhiy.storchakalinkissue34410 messages
2019-08-22 06:45:18serhiy.storchakacreate