> In message <[EMAIL PROTECTED]>, > King Dale writes: > >While looking at the new non-blocking I/O stuff in JDK1.4, it occurred to me > >that there could be a use for a non-blocking matcher. This only applies to > >the AWK stuff as that is the only one that actually works on an input stream > >via the AwkStreamInput (which is a very nice feature that JDK1.4's regex > >package does not have). > > I think the JDK 1.4 package can match on streams because it uses > character sequences. Well, technically I think you can only do it > for files because you can memory map them. It won't work for > a socket.
Right, which is what I said. > At any rate, it's just not clear to me how efficient > java.util.regex is and it's monolithic design is not extensible/reusable. > It would be nice if they included some factories so we could provide > our own implementation of the API and allow for multiple regular > expression syntaxes. Agreed, but quit changing the subject ;-) > While on the subject of JDK 1.4, does anyone have > any suggestions for multi-platform support from a single Java source > base short of using the C preprocessor? For a long time I've wanted > to generate separate jars for J2ME, JDK 1.1, 1.2, and 1.3. I'd > also like to start supporting JDK 1.4 features like CharSequence. > #ifdef is the best way to do this, but there's been strong resistance > to using cpp in the past. Hey, don't hijack my thread, start your own thread ;-) > >Instead of having the matcher be a pull model where it blocks waiting for > >input data, you instead push data to it and when it sees a match it notifies > >a listener via an event. Instead of giving it a stream input to read from, > >it would act as FilterOutputStream and moinitor the data that passes through > >it. > > This would work with the awk package, but not the Perl stuff unless > you imposed a maximum lookahead the way expect used to do the last > time I ever used it (same reason why Perl5StreamInput disappeared > between the last OROMatcher release and the first jakarta-oro release). Which is why I said, "This only applies to the AWK stuff as that is the only one that actually works on an input stream via the AwkStreamInput." > As I understand it, you should have no trouble building this by > funneling data from a PipedOutputStream to a PipedInputStream (or > get the appropriate streams from java.nio.Pipe). Which ignores the whole reason for doing it! The idea is that you would like to scan from many sockets at once. You do not want to devote a thread to each connection because that does not scale well. You still have a thread at the receiving end of each of those pipes. That is the whole reason for the selectable channels in the new 1.4 IO API's. To allow you to handle many simultaneous connections without devoting a thread to each and having each thread blocking on data to be available. You have a selector from which you can determine a channel that is "ready". You could handle many connections with a single thread or a pool of threads. The idea would be a I would read data from a channel that had data available and push it to a matcher. That matcher would maintain state between pushes of data to it, but would not itself block to wait on data available. I agree that there probably isn't much need for this sort of thing, but since a Matcher is a DFA, which is a state machine, it shouldn't actually be that hard either. -- Dale King
