On 7/12/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
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.
Thanks Tim. I'll remove these unstable tests from NIO module.
Does that make sense?
Are you thinking of pursuing an impl test then?
For this specific case, the impl test will be very complicated, because
begin/end are final,
and OSNetworkSystem.getOSNetworkSystem() is static. We need to do lots of
things to inject mocked class into DatagramChannel.read method.
Personally, I'm not inclined to test this method. :) What's your opinion?
Any comments? Thanks!
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]
--
Andrew Zhang
China Software Development Lab, IBM
