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