Should parallel iterators support `copy.copy`?

MutithreadIterators and MultiprocessIterator don’t correctly handles copy.copy. I propose to make MultithreadIterator.__copy__ and Multiprocessiterator.__copy__ raise NotImplementedError, if Chainer developers agreed.

Even though MultiprocessIterator once implemented (hopefully) correct __copy__ function (#3076), current code lacks some additional arguments. MultithreadIterator doesn’t implement __copy__ at all.

Currently there are very simple working tests about copy.copy as below. But these tests don’t ensure correct handling of race conditions, resource managements and etc.

• https://github.com/chainer/chainer/blob/v6.0.0b1/tests/chainer_tests/iterators_tests/test_multithread_iterator.py#L234
• https://github.com/chainer/chainer/blob/v6.0.0b1/tests/chainer_tests/iterators_tests/test_multiprocess_iterator.py#L272

I’m not sure about MultiNodeIteratorMaster or MultiNodeIteratorSlave, whereas I guess the situation is not much different.

In Chainer core, only this line uses copy.copy(iterator), and the usage is just a fallback of Itrator.reset. Both MultithreadIterator and MutliprocessIterator supports reset method.

• https://github.com/chainer/chainer/blob/v6.0.0b1/chainer/training/extensions/evaluator.py#L205

The other usage founds in an example. This example uses a custom iterator, so it is unrelated.

• https://github.com/chainer/chainer/blob/v6.0.0b1/examples/ptb/train_ptb_custom_loop.py#L59

[Crissman]

Copy.copy approach has been replaced by the reset method, but for backward compatibility, we do not want to replace copy.copy with a NotImplementedError. We will raise a PR to add clarity to this.

[Crissman]

#5882 merged, so closing.