Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44B38ADA.7000408@pobox.com>
Date: Tue, 11 Jul 2006 07:26:18 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][nio] How to deal with unstable but useful tests?
References: <4d0b24970607110004h2e12280es947c0f94dd0f97de@mail.gmail.com>
	 <44B35420.7000003@gmail.com>
 <4d0b24970607110049v506b31a2h2c82877fa853f2a8@mail.gmail.com>
 <44B383FB.4070101@gmail.com>
In-Reply-To: <44B383FB.4070101@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Don't we want to be able to tell if a thread is Blocked anyway?

geir

Tim Ellison 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.
> 
> Does that make sense?
> 
> 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
>>>
>>>
>>
> 


---------------------------------------------------------------------
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