Probably "stop condition" won't work at all, because parallel threads wont even notice, that some thread rejected some value. At this moment LimitSpliterator is not prepared for parallel executions at all: it uses default split method which buffers results.
Parallel stream limit has undefined behaviour.
Probably "stop condition" won't work at all, because parallel threads wont even notice, that some thread rejected some value. At this moment LimitSpliterator is not prepared for parallel executions at all: it uses default split method which buffers results.
It works perfectly for parallel list, and hashset, and even IntStream. I have no idea what should be done to generate wrong results.
Spliterator has well defined contract and default implementation of LimitSpliterator gives perfect semantic although limited paralelization.
Limited paralelization means that "filtering" is done internally in single thread, but all other pipeline steps are still parallel. In fact that's exactly what we want to achieve.
bulshit, not a bug.
It works perfectly for parallel list, and hashset, and even IntStream. I have no idea what should be done to generate wrong results.
Spliterator has well defined contract and default implementation of LimitSpliterator gives perfect semantic although limited paralelization.
Limited paralelization means that "filtering" is done internally in single thread, but all other pipeline steps are still parallel. In fact that's exactly what we want to achieve.
Parallel stream limit has undefined behaviour.
Probably "stop condition" won't work at all, because parallel threads wont even notice, that some thread rejected some value. At this moment LimitSpliterator is not prepared for parallel executions at all: it uses default split method which buffers results.
To be honest, our current, default method "trySplit" uses condition all the time and preserves condition?
bulshit, not a bug.
It works perfectly for parallel list, and hashset, and even IntStream. I have no idea what should be done to generate wrong results.
Spliterator has well defined contract and default implementation of LimitSpliterator gives perfect semantic although limited paralelization.
Limited paralelization means that "filtering" is done internally in single thread, but all other pipeline steps are still parallel. In fact that's exactly what we want to achieve.