Correct thread issue during Android copy/move - Thread.yield()

[iBotPeaches]

In memory starved or slow devices during the process of lodging many copy operations. We find some odd behavior that leads to the previous copies obtaining the copied file from the last iteration ran.

Lets say I am copying 3 photos

• cat.jpg
• dog.jpg
• fish.jpg

In that order. When the memory is intentionally starved or device is slowed down. We will find that (cat.jpg/dog.jpg) during the copy operation actually become fish.jpg. This behavior started after the merge of: #597

I started investigating how this could happen and I landed on this Thread.yield() line, which seems quite suspicious after reading the docs

A hint to the scheduler that the current thread is willing to yield its current use of a processor. The scheduler is free to ignore this hint.

Yield is a heuristic attempt to improve relative progression between threads that would otherwise over-utilise a CPU. Its use should be combined with detailed profiling and benchmarking to ensure that it actually has the desired effect.

It is rarely appropriate to use this method. It may be useful for debugging or testing purposes, where it may help to reproduce bugs due to race conditions.

So in one simple test I removed Thread.yield() and I could no longer replicate the issue. I believe this is the culprit for some of the odd reported issues. My guess is even though the executor is held to 1 queue due to the async nature of the calls and variety of OS - some may yield to the next pending task, which then collides on the variables and causes corruption/copies, etc.