Wouldn't there still be a thread per parser then, since the SAX parser would block in the InputStream? In which case, why bother with NIO?
Note: since NIO is currently limited to 64 sockets at a time on windows, the actual perf gain is going to be small, if any, for that platform. Chris Chen <[EMAIL PROTECTED]> writes: > Well, I'm thinking of another way of wrapping a underlying stream > into a "faked blocking IO stream" for SAX. > > What you can do is have NIO on one side, put all the data into a > channel, then create a data buffer processor that reads in the data > from the channel. This processor will also implement the > InputStream interface so that it can be read... Then you can just > pass the wrapped stream to the SAX handler. This way, SAX still > thinks it's using a traditional stream but the underlying > implementation is actually using the new NIO. > > I think this might work, but you do have to implement your own > blocking mechanism for the read() operation. > > Chris > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- Joe Hildebrand Chief Architect Jabber, Inc. http://www.jabber.com/ _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
