<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: What is a stream?</title>
	<atom:link href="http://www.lambdafaq.org/what-is-a-stream/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lambdafaq.org/what-is-a-stream/</link>
	<description>Your questions answered: all about Lambdas and friends</description>
	<lastBuildDate>Wed, 23 Sep 2020 15:06:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.2.38</generator>
	<item>
		<title>By: naftalin</title>
		<link>http://www.lambdafaq.org/what-is-a-stream/#comment-24772</link>
		<dc:creator><![CDATA[naftalin]]></dc:creator>
		<pubDate>Sun, 28 Jul 2013 19:30:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.lambdafaq.org/?p=904#comment-24772</guid>
		<description><![CDATA[Interesting. I agree that the spec is inconsistent with the implementation of fail-fast iterators, which don&#039;t allow any structural modification to their collection once they have been constructed. The motivation for that rule is to detect concurrent collection modification at any time, since any concurrent modification was considered an error for the non-threadsafe collections that use fail-fast iterators.  Here the view taken is more relaxed: concurrent modification is in fact only dangerous if it takes place after processing has begun.  I don&#039;t see that this view is harder either to enforce or to describe.

Of course, none of this applies to concurrent collections; concurrent modification is expected both during iteration and stream processing.]]></description>
		<content:encoded><![CDATA[<p>Interesting. I agree that the spec is inconsistent with the implementation of fail-fast iterators, which don&#8217;t allow any structural modification to their collection once they have been constructed. The motivation for that rule is to detect concurrent collection modification at any time, since any concurrent modification was considered an error for the non-threadsafe collections that use fail-fast iterators.  Here the view taken is more relaxed: concurrent modification is in fact only dangerous if it takes place after processing has begun.  I don&#8217;t see that this view is harder either to enforce or to describe.</p>
<p>Of course, none of this applies to concurrent collections; concurrent modification is expected both during iteration and stream processing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
