Geir Magnusson Jr wrote:
> Don't we want to be able to tell if a thread is Blocked anyway?
Do you mean on a monitor (=yes) or in the OS? The VM may choose to do
deadlock detection etc. but the classlib doesn't care.
Regards,
Tim
> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
