Author xiang.zhang
Recipients carlorosati, davin, rhettinger, xiang.zhang, xtreak
Date 2018-08-21.03:48:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1534823315.85.0.56676864532.issue34410@psf.upfronthosting.co.za>
In-reply-to
Content
It seems to me the problem is tee objects might encounter race conditions while  `PyIter_Next` in `teedataobject_getitem` releases GIL. Other threads then might get into the same branch since `tdo->numread` haven't been updated yet. NULL slots are generated then, 2 objects are read from the underlying iterator and `tdo->numread` is updated twice while only one slot is set.

As for multiprocessing.pool, there is a background task handling thread consuming one tee object and main thread consuming another one. The underlying iterator is `IMapIterator` which `next` method would block on a condition.

While trying, I find the following snippet would also crash:

import threading
import itertools

class C:
    def __iter__(self):
        return self
    def __next__(self):
        return 1

def test(i):
    print(list(i))

i1, i2 = itertools.tee(C())
threading.Thread(target=test, args=(i1,)).start()
print(list(i2))

GDB shows it crashs in `teedataobject_dealloc` -> `teedataobject_clear`. I haven't understood what happened.
History
Date User Action Args
2018-08-21 03:48:35xiang.zhangsetrecipients: + xiang.zhang, rhettinger, davin, xtreak, carlorosati
2018-08-21 03:48:35xiang.zhangsetmessageid: <1534823315.85.0.56676864532.issue34410@psf.upfronthosting.co.za>
2018-08-21 03:48:35xiang.zhanglinkissue34410 messages
2018-08-21 03:48:35xiang.zhangcreate