On Thu, 22 Jul 2004 03:14:37 +0900, Atsushi Eno <[EMAIL PROTECTED]> wrote: > Hello, > > Assuming you also wanted to reply to the list... > Oops :)
> David Waite wrote: > > > I might be misunderstanding the problem, but... > > > > It seems like the stream could simply be Read() from; if there is no > > data, the read will block, if there is data it can go into an internal > > buffer. That buffer gets examined to see if there is enough > > information to identify and represent the next event in the pull > > parser; if not, you call Read() again, which may block again. MoveTo* > > and Read* methods will just keep reading until the conditions > > specified by the method are satisfied. > > What I've written in the previous post is "how Read() events do not > match with the *required* text stream consumption for one Read() call". > The TextReader (stream) is likely to be set as empty (not set any > contents) and thus it easily freezes. In such case are those stream > developers aware of how XmlTextReader consumes the stream at any time? My misunderstanding - I thought you were saying in your previous message that reading from the stream only when a Read() or Next*() was called was impossible; it is possible, because you are doing it already in your code :) What is infeasable is reading byte-by-byte, just enough to determine the node type. Yes, a Stream Read(byte[], int, int) is not meant to block until the length is met. You may read more into an internal buffer than is needed to represent the next event, but you will not block waiting for more than needed. > (BTW MoveTo*() never consumes the stream. Those methods must be > available for iterating attributes.) Sorry, yes, only MoveToContent() performs reading. <snip> -David Waite _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
