Should ParVec have poisoning behavior for panics?

[abonander]

A thread panicking while operating on a ParSlice could leave an incomplete result, similar to what would happen if a thread panicked while holding a MutexGuard or a RWLockWriteGuard. This suggests that ParSlice should have similar poisoning behavior.

However, poisoning a whole vector just because a thread panicked while holding a subslice seems like overkill. As a compromise, unwrapping a ParVec could return two vectors: one with all the elements from healthy (unpoisoned) subslices, and one with the contaminated elements from poisoned subslices. This would add complexity to the implementation as subslices are currently only tracked via the strong refcount on Arc, and would also require additional allocations where the current API uses existing storage.

But I would also argue that ParVec should not poison altogether, because it does not allow actual concurrent (or mutually exclusive) access to its elements; each is only ever touched by either the originating thread, or the thread that its containing ParSlice was sent to, and never at the same time, mutably or otherwise. In this way, incomplete results seem more like a logic error than undefined behavior, and thus should be handled by the user.

It is clear some discussion is merited here. Is ParVec safe as it is, or is it hiding dangerous, undefined behavior behind a "safe" API?

cc @gankro, @huonw

[reem]

It seems reasonable to me to just poison the entire vector, and allow the user to recover from poisoning the same way Mutex and RwLock do.

[reem]

It should be noted that poisoning is not actually necessary for safety reasons, it's just a nice-to-have as it makes the behavior under panics a bit more reasonable.