[scala-bts] #1920: XMLEventReader iterator interface

---------------------+------------------------------------------------------
Reporter: rbpasker | Owner: scala-xml_team
Type: defect | Status: new
Priority: normal | Component: XML support
Keywords: |
---------------------+------------------------------------------------------
On #scala, there has been considerable discussion over multithreaded
parsing support in XMLEventReader.

The underlying problem is that the spawned reader/parser thread
communicates with the main thread via a j.u.c.BlockingLinkedQueue. Since
the reader/parser thread modifies the underlying collection, a for
comprehension on the iterator does not necessarily return all the
elements.

The Iterator interface says:

"The behavior of an iterator is unspecified if the underlying collection
is modified while the iteration is in progress in any way other than by
calling [the remove] method."
http://java.sun.com/javase/6/docs/api/java/util/Iterator.html

The current solution (considerable work by PaulP) is to guarantee that
"while (hasNext()) next();" works correctly for XMLEventReader, even while
the underlying collection undergoes modification by the reader/parser
thread.

There are a few different solutions to this:

1. don't worry, be happy

2. modify the XMLEventReader documentation to clarify that it guarantees
hasNext/next works correctly under modification

3. add a new trait BlockingIterator which has the desired semantics, and
have XMLEventReader implement that

4. fix j.u.c.LinkedBlockingQueue.hasNext() so it blocks

5. make comprehensions over iterators in Scala handle
NoSuchElementException gracefully so that the hasNext() behavior can
always return true, and next() can always block waiting for the next
element

6. fix iteration in Scala to have clearer semantics

I would recommend 3