harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][nio] How to deal with unstable but useful tests?
Date Tue, 11 Jul 2006 16:41:35 GMT
Andrew Zhang wrote:
> On 7/11/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>
>> I hadn't appreciated that the read call is blocking...
>>
>> So how about you do the blocking read() in a new thread, then the main
>> thread can poll to wait until the reading thread's state is Blocked,
>> before closing the channel and forcing the exception?
>>
>> The problem is that the thread will be detached from the VM and blocking
>> in the OS for the read, so not officially Java Blocked.  You can only
>> determine OS blocked state via additional native code.
>>
>> Therefore, as Paulex wrote, if you are not writing additional native
>> code for your test you may have to actually synchronize on the reading
>> thread having passed begin(), not when it is actually read() blocked.
> 
> 
> Yes. As Paulex suggested,  we have to write implementation test rather than
> api test.

Yes, I think that's right.  I don't see any portable way to detect the
blocking call in progress, so I don't see how we can make this an API
test case.  Anyone else have any ideas?

> So is the orignal test valuable? In other words, shall we keep it in api
> tests?

No, the original delay() version is not going to work when the threads
are scheduled on different processors.

> Does that make sense?

Are you thinking of pursuing an impl test then?

Regards,
Tim


>> Andrew Zhang wrote:
>> > Hello Tim,
>> >
>> > Thank you for your suggestion. :)
>> >
>> > Of course, "fix" is the best choice. I also have tried to use
>> > "wait/notify",
>> > but found it didn't work for this case.
>> >
>> > Please note that "channel1.read(targetBuf); // Label 3" is a blocking
>> > operation. And we want code at label 1,2 to execute after label 3.
>> >
>> > There is the question:
>> >
>> > Where should I put "notify"?
>> >
>> > 1. before "read"? NO. If nofity is put before read, then we still can't
>> > guarantee "configureBlocking" is executed after read.
>> > 2. after "read"? NO. read is a blocking operatoin. It will never be
>> > executed
>> > if put notify after read.
>> > 3. in "read"?  Obviously NO.
>> >
>> > Please correct me if I'm wrong.
>> >
>> > Thanks!
>> >
>> >
>> > On 7/11/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> >>
>> >> Andrew Zhang wrote:
>> >> > Hello everybody,
>> >> >
>> >> > I noticed such tests in DatagramChannel, which is useful, but
>> >> potentially
>> >> > unstable.  Consider:
>> >> >
>> >> > public void testReadWrite_configureBlock() throws Exception {
>> >> >        byte[] targetArray = new byte[2];
>> >> >        // bind and connect
>> >> >        this.channel1.socket().bind(localAddr2);
>> >> >        this.channel1.connect(localAddr1);
>> >> >        this.channel2.socket().bind(localAddr1);
>> >> >        this.channel2.connect(localAddr2);
>> >> >        ByteBuffer targetBuf = ByteBuffer.wrap(targetArray);
>> >> >
>> >> >        new Thread() {
>> >> >            public void run() {
>> >> >                try {
>> >> >                    Thread.sleep(TIME_UNIT);
>> >> >                    channel1.configureBlocking(false); // Label 1
>> >> >                    channel1.close(); // Label 2
>> >> >                } catch (Exception e) {
>> >> >                    //ignore
>> >> >                }
>> >> >            }
>> >> >        }.start();
>> >> >        try {
>> >> >            this.channel1.read(targetBuf); // Label 3
>> >> >            fail("should throw AsynchronousCloseException");
>> >> >        } catch (AsynchronousCloseException e) {
>> >> >            // ok
>> >> >        }
>> >> >    }
>> >> > This test assumes Label 3  code should execute before Label 1 and
>> Label
>> >> 2,
>> >> > which is right in most cases, because the code invokes "Thread.sleep
>> >> > (TIME_UNIT)".
>> >> >
>> >> > However, it's potentially unstable. It heavily depends on TIME_UNIT
>> >> value,
>> >> > test environment (Hardware, OS ...)
>> >>
>> >> Urgh.  There are *very* few occasions when you need to use
>> >> Thread.sleep(); and 'thread synchronization' is definitely not one of
>> >> them!
>> >>
>> >> If you have order dependencies between two or more threads then use
>> >> wait/notify, or synchronized, and make them explicit.
>> >>
>> >> There are any number of books on multi-threaded programming in Java.
>> >>
>> >> > Indubitably, the test is very useful for testing
>> >> > "AsynchronousCloseException" of DatagramChannel.read(ByteBuffer)
>> >> method.
>> >> >
>> >> > How shall we deal with such issue?  Deleting such valuable tests is
>> not
>> >> a
>> >> > wise decision, while keeping them may cause build system fail.
>> >> >
>> >> > One solution I could image is TestNG. :) i.e. Use "@dev" or
>> >> something to
>> >> > mark such tests, say, the tests are only for developing purpose.
>> >> >
>> >> > Any suggestions?
>> >>
>> >> Fix it!  :-)
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >> --
>> >>
>> >> Tim Ellison (t.p.ellison@gmail.com)
>> >> IBM Java technology centre, UK.
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> -- 
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message