Andrew Zhang wrote:
> On 7/11/06, Tim Ellison <[EMAIL PROTECTED]> 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 <[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]
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> 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]
>>
>>
>
>
--
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]
