W3C home > Mailing lists > Public > html-tidy@w3.org > April to June 2002

Re: Using JTidy in threads with piped IO streams

From: Rick Beton <richard.beton@dsl.pipex.com>
Date: Mon, 10 Jun 2002 15:27:10 -0400 (EDT)
Message-ID: <3D04FE77.30902@dsl.pipex.com>
To: Armin Braun <brar0013@fh-karlsruhe.de>, html-tidy@w3.org

Armin Braun wrote:

>I'm currently working on a problem with JTidy and threads. Just the simple
>producer-consumer example; I created two threads and let the first one
>parse an URL stream with JTidy and write to an output stream, while the
>other one reads this output from an input stream. I used the classes
>PipedInputStream and PipedOutputStream to connect the two of them.
>However, this won't work. The input stream connected to the outputstream
>(the latter should be written by JTidy) doesn't seem to contain any data,
>as I checked using its "available()" method. Outputting to a file e.g.
>works perfectly; so it's not a reason of the original URL stream.
>Sometimes it seems there's no data available, sometimes nothing happens as
>if the threads were deadlocking each other. I tried as much as I could,
>but nothing worked unfortunately.
>Maybe someone has an idea of how to solve that problem, or even some
>sample code to throw a glance at.

Not sure if this is quite what you need, but I personally prefer to 
connect threads using CSP channels. (Occam programmers of old will 
recognise this of course.) See University of Kent website 

Basically, you create a One2OneChannel interface (javadoc: 
and use each end of it in your two communicating threads. The advantage 
of this over the standard java.io pipes is that there is a suite of 
channels, various plug-in buffers, etc, and most importantly 
*alternation* (similar to Unix 'select'). The suite itself guarantees 
deadlock freedom internally, proven by the theorists at Kent. You can 
therefore use a correct-by-construction approach to ensure your design 
doesn't deadlock when constructed from these elements.

Conversely, the advantage of the java.io pipes approach is that it plugs 
into other java.io streams and filters. However, when I looked at the 
source code, I was a bit unhappy about whether the pipe classes might 
contain possibilities for deadlock though. But that was ages ago and 
they may be better now.

 From an efficiency point of view, prefer JCSP channels over 
java.io.pipes every time!

Rick :-)
Received on Monday, 10 June 2002 17:41:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:52 UTC