From zhong.j.yu at gmail.com  Thu Mar  1 14:52:02 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 1 Mar 2012 16:52:02 -0600
Subject: AsynchronousFileChannel.open() - is it blocking?
Message-ID: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>

Is open() a potentially blocking action? Apparently so because some
sanity checking (e.g. existence of the file) requires disk spin. If
that's the case, it should probably be explicitly documented.

And after open(), are following methods blocking or non-blocking?

    size();
    truncate();

Thanks,
Zhong Yu

From vitalyd at gmail.com  Thu Mar  1 15:02:21 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 1 Mar 2012 18:02:21 -0500
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
Message-ID: <CAHjP37GmmRuucaGB-OvTMz8JK3_2aQbL+KembaPUSvBC8NAyfg@mail.gmail.com>

It's probably safe to assume that any method that doesn't return a Future
or accepts a CompletionHandler runs synchronously.

On Thu, Mar 1, 2012 at 5:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> Is open() a potentially blocking action? Apparently so because some
> sanity checking (e.g. existence of the file) requires disk spin. If
> that's the case, it should probably be explicitly documented.
>
> And after open(), are following methods blocking or non-blocking?
>
>    size();
>    truncate();
>
> Thanks,
> Zhong Yu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120301/66cf6093/attachment.html 

From zhong.j.yu at gmail.com  Thu Mar  1 15:52:26 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 1 Mar 2012 17:52:26 -0600
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CAHjP37GmmRuucaGB-OvTMz8JK3_2aQbL+KembaPUSvBC8NAyfg@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
	<CAHjP37GmmRuucaGB-OvTMz8JK3_2aQbL+KembaPUSvBC8NAyfg@mail.gmail.com>
Message-ID: <CACuKZqGkuHFhJmnhG4oW3yXQP8SFRNCDEsWv04N_SQYV-+PqDg@mail.gmail.com>

A synchronous action can be blocking or non-blocking. I'm asking the
blocking aspect.

On Thu, Mar 1, 2012 at 5:02 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> It's probably safe to assume that any method that doesn't return a Future or
> accepts a CompletionHandler runs synchronously.
>
>
> On Thu, Mar 1, 2012 at 5:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> Is open() a potentially blocking action? Apparently so because some
>> sanity checking (e.g. existence of the file) requires disk spin. If
>> that's the case, it should probably be explicitly documented.
>>
>> And after open(), are following methods blocking or non-blocking?
>>
>> ? ?size();
>> ? ?truncate();
>>
>> Thanks,
>> Zhong Yu
>
>

From vitalyd at gmail.com  Thu Mar  1 16:10:24 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 1 Mar 2012 19:10:24 -0500
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CACuKZqGkuHFhJmnhG4oW3yXQP8SFRNCDEsWv04N_SQYV-+PqDg@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
	<CAHjP37GmmRuucaGB-OvTMz8JK3_2aQbL+KembaPUSvBC8NAyfg@mail.gmail.com>
	<CACuKZqGkuHFhJmnhG4oW3yXQP8SFRNCDEsWv04N_SQYV-+PqDg@mail.gmail.com>
Message-ID: <CAHjP37GdWP1sMV3PL3MrPQe=wsRqyVaGRykbQH_Y3p8SHTv0iQ@mail.gmail.com>

I'm not sure what distinction you're trying to draw in async/sync vs
non-blocking/blocking.  Can you clarify that part? In general, non-blocking
is analogous to async and blocking to synchronous in terms of whether the
caller is blocked or not -- you can certainly have a synchronous/blocking
call that's actually implemented asynchronously internally, but from the
caller's perspective it's a blocking call as control does not return until
the method completes.

Are you instead asking whether any physical i/o will be triggered?

On Thu, Mar 1, 2012 at 6:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> A synchronous action can be blocking or non-blocking. I'm asking the
> blocking aspect.
>
> On Thu, Mar 1, 2012 at 5:02 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > It's probably safe to assume that any method that doesn't return a
> Future or
> > accepts a CompletionHandler runs synchronously.
> >
> >
> > On Thu, Mar 1, 2012 at 5:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> >>
> >> Is open() a potentially blocking action? Apparently so because some
> >> sanity checking (e.g. existence of the file) requires disk spin. If
> >> that's the case, it should probably be explicitly documented.
> >>
> >> And after open(), are following methods blocking or non-blocking?
> >>
> >>    size();
> >>    truncate();
> >>
> >> Thanks,
> >> Zhong Yu
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120301/96fbed36/attachment.html 

From zhong.j.yu at gmail.com  Thu Mar  1 17:02:25 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Thu, 1 Mar 2012 19:02:25 -0600
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CAHjP37GdWP1sMV3PL3MrPQe=wsRqyVaGRykbQH_Y3p8SHTv0iQ@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
	<CAHjP37GmmRuucaGB-OvTMz8JK3_2aQbL+KembaPUSvBC8NAyfg@mail.gmail.com>
	<CACuKZqGkuHFhJmnhG4oW3yXQP8SFRNCDEsWv04N_SQYV-+PqDg@mail.gmail.com>
	<CAHjP37GdWP1sMV3PL3MrPQe=wsRqyVaGRykbQH_Y3p8SHTv0iQ@mail.gmail.com>
Message-ID: <CACuKZqHe-X_uk+RP5oW7Y1pg5XUYqJZ7MysL4yL-i9rOA3kRZg@mail.gmail.com>

Yes, I'm asking whether during open() call, the thread can be
suspended due to slow external IO. Same goes to size() and truncate().

Since the class is labeled as "Asynchronous", one might overlook the
fact that some methods could suspend the calling thread. If one is
writing a so called asynchronous web server for example, such methods
must be invoked specially. It might be worthwhile to put the fact in
the javadoc.

Pardon me if the answer is too obvious.But I didn't see definitively
why open() couldn't always return immediately, by bundling any IO
actions involved to later read/write actions. For example, if it takes
a while to discover that the file doesn't exist, the error can be
raised after open(), in a completion handler for a read/write. I would
prefer this mode.

Zhong

On Thu, Mar 1, 2012 at 6:10 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> I'm not sure what distinction you're trying to draw in async/sync vs
> non-blocking/blocking. ?Can you clarify that part? In general, non-blocking
> is analogous to async and blocking to synchronous in terms of whether the
> caller is blocked or not -- you can certainly have a synchronous/blocking
> call that's actually implemented asynchronously internally, but from the
> caller's perspective it's a blocking call as control does not return until
> the method completes.
>
> Are you instead asking whether any physical i/o will be triggered?
>
>
> On Thu, Mar 1, 2012 at 6:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> A synchronous action can be blocking or non-blocking. I'm asking the
>> blocking aspect.
>>
>> On Thu, Mar 1, 2012 at 5:02 PM, Vitaly Davidovich <vitalyd at gmail.com>
>> wrote:
>> > It's probably safe to assume that any method that doesn't return a
>> > Future or
>> > accepts a CompletionHandler runs synchronously.
>> >
>> >
>> > On Thu, Mar 1, 2012 at 5:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>> >>
>> >> Is open() a potentially blocking action? Apparently so because some
>> >> sanity checking (e.g. existence of the file) requires disk spin. If
>> >> that's the case, it should probably be explicitly documented.
>> >>
>> >> And after open(), are following methods blocking or non-blocking?
>> >>
>> >> ? ?size();
>> >> ? ?truncate();
>> >>
>> >> Thanks,
>> >> Zhong Yu
>> >
>> >
>
>

From Alan.Bateman at oracle.com  Fri Mar  2 00:46:43 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 02 Mar 2012 08:46:43 +0000
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
Message-ID: <4F5088F3.9000203@oracle.com>

On 01/03/2012 22:52, Zhong Yu wrote:
> Is open() a potentially blocking action? Apparently so because some
> sanity checking (e.g. existence of the file) requires disk spin. If
> that's the case, it should probably be explicitly documented.
>
> And after open(), are following methods blocking or non-blocking?
>
>      size();
>      truncate();
>
The asynchronous operations defined by AsynchronousFileChannel are read, 
write, and lock. The other methods, including the open method to create 
or open the file, are synchronous and potentially blocking.

-Alan.


From zhong.j.yu at gmail.com  Fri Mar  2 05:46:35 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 2 Mar 2012 07:46:35 -0600
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <4F5088F3.9000203@oracle.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
	<4F5088F3.9000203@oracle.com>
Message-ID: <CACuKZqFE9WThFBt46oXLCfsO3kc_wx2qfQWkGRdU4Z7gZ1G_ag@mail.gmail.com>

Thanks Alan.

Are you sure about size()? If a file is open, reading its size
attribute may require IO?

And what about close()? Could it also block?

Zhong Yu

On Fri, Mar 2, 2012 at 2:46 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 01/03/2012 22:52, Zhong Yu wrote:
>>
>> Is open() a potentially blocking action? Apparently so because some
>> sanity checking (e.g. existence of the file) requires disk spin. If
>> that's the case, it should probably be explicitly documented.
>>
>> And after open(), are following methods blocking or non-blocking?
>>
>> ? ? size();
>> ? ? truncate();
>>
> The asynchronous operations defined by AsynchronousFileChannel are read,
> write, and lock. The other methods, including the open method to create or
> open the file, are synchronous and potentially blocking.
>
> -Alan.
>

From vitalyd at gmail.com  Fri Mar  2 05:55:24 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 2 Mar 2012 08:55:24 -0500
Subject: AsynchronousFileChannel.open() - is it blocking?
In-Reply-To: <CACuKZqFE9WThFBt46oXLCfsO3kc_wx2qfQWkGRdU4Z7gZ1G_ag@mail.gmail.com>
References: <CACuKZqHv7BfEZLtDVQHDrt-KzhuvRPh96qtWBw5QLwt_w5EFKA@mail.gmail.com>
	<4F5088F3.9000203@oracle.com>
	<CACuKZqFE9WThFBt46oXLCfsO3kc_wx2qfQWkGRdU4Z7gZ1G_ag@mail.gmail.com>
Message-ID: <CAHjP37GkUzCocmCw9Cn2fNST61o0p=nr1Duzew=sD_Cfy_WVPw@mail.gmail.com>

If the file metadata has been evicted from the page cache, then size() may
require i/o.  truncate() probably does not unless you force/fsync() the
file afterwards.  close() should also not require i/o in typical use.
 However, you can't rely on this as it's platform/OS/file system specific.

On Fri, Mar 2, 2012 at 8:46 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> Thanks Alan.
>
> Are you sure about size()? If a file is open, reading its size
> attribute may require IO?
>
> And what about close()? Could it also block?
>
> Zhong Yu
>
> On Fri, Mar 2, 2012 at 2:46 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> > On 01/03/2012 22:52, Zhong Yu wrote:
> >>
> >> Is open() a potentially blocking action? Apparently so because some
> >> sanity checking (e.g. existence of the file) requires disk spin. If
> >> that's the case, it should probably be explicitly documented.
> >>
> >> And after open(), are following methods blocking or non-blocking?
> >>
> >>     size();
> >>     truncate();
> >>
> > The asynchronous operations defined by AsynchronousFileChannel are read,
> > write, and lock. The other methods, including the open method to create
> or
> > open the file, are synchronous and potentially blocking.
> >
> > -Alan.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120302/bedf040c/attachment-0001.html 

From luchsh at linux.vnet.ibm.com  Sun Mar 11 19:45:43 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 12 Mar 2012 10:45:43 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
Message-ID: <4F5D6357.6000400@linux.vnet.ibm.com>

Copy to security-dev and nio-dev since files from these two modules are 
also included in this patch.

-Jonathan

-------- Original Message --------
Subject: 	Remove including of link.h to improve portability
Date: 	Fri, 9 Mar 2012 19:49:06 +0800
From: 	Jonathan Lu <luchsh at linux.vnet.ibm.com>
To: 	2d-dev at openjdk.java.net



Hello 2d-dev,

I find that link.h is included in several place of OpenJDK code, mostly 
together with dlfcn.h, but this caused portability problem in my testing 
on some Unix platforms, such as AIX.
So far as I see OpenJDK only makes use of basic POSIX.1-2001 compatible 
dynamic library manipulation functions, such as dlopen, dlclose, dlsym, 
dlerr functions, no other extensions found, so is link.h still 
neccessary for current implementation? because link.h is not found in 
the c-POSIX standard headers 
(http://en.wikipedia.org/wiki/C_POSIX_library) and I think this removal 
will be an enhancement for portability, does that make sense?

Here's the proposed patch, since most parts of it are from Java2d so I 
post it here for discussion.
http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
<http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>

And one more question, in 
src/solaris/native/sun/java2d/x11/XRBackendNative.c I found following 
comments
  #ifdef __solaris__
  /* Solaris 10 will not have these symbols at runtime */
  #include <link.h>

And in src/solaris/native/sun/awt/fontpath.c,
  #include <dlfcn.h>
  #ifndef __linux__ /* i.e. is solaris */
  #include <link.h>
  #endif

I've built successfully on Ubuntu 11.10 32bit and OpenSolaris Express 
2010.11 x86, the patch seems to be OK, but does anybody know the 
situation on Solaris (e.g. Solaris 10) of this problem?
I assume it will also comply with POSIX.1-2001 standard, and provide all 
the required functions in dlfcn.h, right?

Cheers!
- Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120312/dee3534b/attachment.html 

From chuanshenglu at gmail.com  Sun Mar 11 20:29:59 2012
From: chuanshenglu at gmail.com (Jonathan Lu)
Date: Mon, 12 Mar 2012 11:29:59 +0800
Subject: Remove including of link.h to improve portability
In-Reply-To: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
Message-ID: <4F5D6DB7.2070101@gmail.com>

Bug 7152519 has been created for this patch.

- Jonathan

On 03/09/2012 07:49 PM, Jonathan Lu wrote:
> Hello 2d-dev,
>
> I find that link.h is included in several place of OpenJDK code, 
> mostly together with dlfcn.h, but this caused portability problem in 
> my testing on some Unix platforms, such as AIX.
> So far as I see OpenJDK only makes use of basic POSIX.1-2001 
> compatible dynamic library manipulation functions, such as dlopen, 
> dlclose, dlsym, dlerr functions, no other extensions found, so is 
> link.h still neccessary for current implementation? because link.h is 
> not found in the c-POSIX standard headers 
> (http://en.wikipedia.org/wiki/C_POSIX_library) and I think this 
> removal will be an enhancement for portability, does that make sense?
>
> Here's the proposed patch, since most parts of it are from Java2d so I 
> post it here for discussion.
> http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
> <http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>
>
> And one more question, in 
> src/solaris/native/sun/java2d/x11/XRBackendNative.c I found following 
> comments
>  #ifdef __solaris__
>  /* Solaris 10 will not have these symbols at runtime */
>  #include <link.h>
>
> And in src/solaris/native/sun/awt/fontpath.c,
>  #include <dlfcn.h>
>  #ifndef __linux__ /* i.e. is solaris */
>  #include <link.h>
>  #endif
>
> I've built successfully on Ubuntu 11.10 32bit and OpenSolaris Express 
> 2010.11 x86, the patch seems to be OK, but does anybody know the 
> situation on Solaris (e.g. Solaris 10) of this problem?
> I assume it will also comply with POSIX.1-2001 standard, and provide 
> all the required functions in dlfcn.h, right?
>
> Cheers!
> - Jonathan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120312/c72b0805/attachment.html 

From zhangshj at linux.vnet.ibm.com  Mon Mar 12 02:34:05 2012
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Mon, 12 Mar 2012 17:34:05 +0800
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
Message-ID: <4F5DC30D.2000900@linux.vnet.ibm.com>

Hi nio-dev,

In jdk/src/solaris/native/sun/nio/ch/DatagramDispatcher.c, there are 
some invocations of system call sendmsg/recvmsg. The second parameter of 
these 2 calls is a pointer to structure msghdr. The pointer needs to be 
initialized before it can be used. Currently it is initialized with 
#ifdef platform clause and it is NOT initialized properly on AIX. I 
think we can use memset(&m, 0, sizeof(m)) to initialized the pointer 
once for all platforms.

Here is the webrev:
http://cr.openjdk.java.net/~zhangshj/7152948/webrev.00/

-- 
Regards,

Shi Jun Zhang



From Alan.Bateman at oracle.com  Mon Mar 12 03:42:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Mar 2012 10:42:25 +0000
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F5DC30D.2000900@linux.vnet.ibm.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com>
Message-ID: <4F5DD311.8070605@oracle.com>

On 12/03/2012 09:34, Shi Jun Zhang wrote:
> Hi nio-dev,
>
> In jdk/src/solaris/native/sun/nio/ch/DatagramDispatcher.c, there are 
> some invocations of system call sendmsg/recvmsg. The second parameter 
> of these 2 calls is a pointer to structure msghdr. The pointer needs 
> to be initialized before it can be used. Currently it is initialized 
> with #ifdef platform clause and it is NOT initialized properly on AIX. 
> I think we can use memset(&m, 0, sizeof(m)) to initialized the pointer 
> once for all platforms.
>
> Here is the webrev:
> http://cr.openjdk.java.net/~zhangshj/7152948/webrev.00/
>
I see 7152948 has been submitted as an incident, I've moved it to the 
right place as:

7152948: (dc) DatagramDispatcher.c should memset msghdr to make it 
portable to other platforms

The changes look okay to me but I think might be a bit cleaner to do the 
memset just prior to setting msg_iov/msg_iovlen (to keep the 
initialization of the msghdr structure in one place).

While you are there, can you change the value 16 to IOV_MAX? (requires 
limits.h).

-Alan





From Alan.Bateman at oracle.com  Mon Mar 12 04:32:27 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Mar 2012 11:32:27 +0000
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F5D6357.6000400@linux.vnet.ibm.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com>
Message-ID: <4F5DDECB.7080502@oracle.com>

On 12/03/2012 02:45, Jonathan Lu wrote:
>
> :
>
> Here's the proposed patch, since most parts of it are from Java2d so I 
> post it here for discussion.
> http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
> <http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>
The change to sun.nio.fs.GnomeFileTypeDetector looks okay to me although 
you'll need to re-base your patch to jdk8/tl because of the Mac port.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120312/36eaab21/attachment.html 

From philip.race at oracle.com  Mon Mar 12 11:22:40 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 Mar 2012 11:22:40 -0700
Subject: [OpenJDK 2D-Dev] Remove including of link.h to improve portability
In-Reply-To: <4F5D6DB7.2070101@gmail.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6DB7.2070101@gmail.com>
Message-ID: <4F5E3EF0.5040705@oracle.com>

I added two of those includes myself I believe and I doubt I did it 
unless needed
and others apparently found it necessary too. So we need to be sure this 
is OK.
However at least one of those I added dates back to Solaris 8 being the 
build platform
so maybe its no longer needed.

I ran the patch through our internal jprt build system on all platforms 
which
for Solaris uses a recent Solaris 10 update and it built fine. I didn't 
notice
any new warnings on the files I know anything about.

 > 7152519
It was incorrectly submitted as awt, I moved it to 2D.

But I think you should split this into 2 patches.
The above bug can be used for all the 2D ones and push to 2d.

The other one for the nio and security patches can go to the "tl" repo.

-phil.




On 3/11/2012 8:29 PM, Jonathan Lu wrote:
> Bug 7152519 has been created for this patch.
>
> - Jonathan
>
> On 03/09/2012 07:49 PM, Jonathan Lu wrote:
>> Hello 2d-dev,
>>
>> I find that link.h is included in several place of OpenJDK code, 
>> mostly together with dlfcn.h, but this caused portability problem in 
>> my testing on some Unix platforms, such as AIX.
>> So far as I see OpenJDK only makes use of basic POSIX.1-2001 
>> compatible dynamic library manipulation functions, such as dlopen, 
>> dlclose, dlsym, dlerr functions, no other extensions found, so is 
>> link.h still neccessary for current implementation? because link.h is 
>> not found in the c-POSIX standard headers 
>> (http://en.wikipedia.org/wiki/C_POSIX_library) and I think this 
>> removal will be an enhancement for portability, does that make sense?
>>
>> Here's the proposed patch, since most parts of it are from Java2d so 
>> I post it here for discussion.
>> http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
>> <http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>
>>
>> And one more question, in 
>> src/solaris/native/sun/java2d/x11/XRBackendNative.c I found following 
>> comments
>>  #ifdef __solaris__
>>  /* Solaris 10 will not have these symbols at runtime */
>>  #include <link.h>
>>
>> And in src/solaris/native/sun/awt/fontpath.c,
>>  #include <dlfcn.h>
>>  #ifndef __linux__ /* i.e. is solaris */
>>  #include <link.h>
>>  #endif
>>
>> I've built successfully on Ubuntu 11.10 32bit and OpenSolaris Express 
>> 2010.11 x86, the patch seems to be OK, but does anybody know the 
>> situation on Solaris (e.g. Solaris 10) of this problem?
>> I assume it will also comply with POSIX.1-2001 standard, and provide 
>> all the required functions in dlfcn.h, right?
>>
>> Cheers!
>> - Jonathan
>>
>


From chris.hegarty at oracle.com  Mon Mar 12 14:05:06 2012
From: chris.hegarty at oracle.com (chris hegarty)
Date: Mon, 12 Mar 2012 21:05:06 +0000
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F5DD311.8070605@oracle.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com> <4F5DD311.8070605@oracle.com>
Message-ID: <4F5E6502.1030307@oracle.com>

On 12/03/2012 10:42, Alan Bateman wrote:
> ...
> 7152948: (dc) DatagramDispatcher.c should memset msghdr to make it
> portable to other platforms
>
> The changes look okay to me but I think might be a bit cleaner to do the
> memset just prior to setting msg_iov/msg_iovlen (to keep the
> initialization of the msghdr structure in one place).
>
> While you are there, can you change the value 16 to IOV_MAX? (requires
> limits.h).

Yes, this would be better. I also agree with your previous comment.

I ran some builds and tests on Solaris and Linux with the current patch. 
All pass fine. I'll do the same when Shi Jun posts an updated patch.

-Chris.

>
> -Alan
>
>
>
>

From luchsh at linux.vnet.ibm.com  Tue Mar 13 03:14:19 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 13 Mar 2012 18:14:19 +0800
Subject: [OpenJDK 2D-Dev] Remove including of link.h to improve portability
In-Reply-To: <4F5E3EF0.5040705@oracle.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6DB7.2070101@gmail.com> <4F5E3EF0.5040705@oracle.com>
Message-ID: <4F5F1DFB.1020707@linux.vnet.ibm.com>

Hi Phil,

Thanks a lot for the review and testing, I've splited the patch into two 
parts, one for 2D repository and another for TL. Here's the patch for 2D 
repository:

http://cr.openjdk.java.net/~luchsh/7152519/

So could anybody please help to do another review?

Thanks a lot!

- Jonathan

On 03/13/2012 02:22 AM, Phil Race wrote:
> I added two of those includes myself I believe and I doubt I did it 
> unless needed
> and others apparently found it necessary too. So we need to be sure 
> this is OK.
> However at least one of those I added dates back to Solaris 8 being 
> the build platform
> so maybe its no longer needed.
>
> I ran the patch through our internal jprt build system on all 
> platforms which
> for Solaris uses a recent Solaris 10 update and it built fine. I 
> didn't notice
> any new warnings on the files I know anything about.
>
> > 7152519
> It was incorrectly submitted as awt, I moved it to 2D.
>
> But I think you should split this into 2 patches.
> The above bug can be used for all the 2D ones and push to 2d.
>
> The other one for the nio and security patches can go to the "tl" repo.
>
> -phil.
>
>
>
>
> On 3/11/2012 8:29 PM, Jonathan Lu wrote:
>> Bug 7152519 has been created for this patch.
>>
>> - Jonathan
>>
>> On 03/09/2012 07:49 PM, Jonathan Lu wrote:
>>> Hello 2d-dev,
>>>
>>> I find that link.h is included in several place of OpenJDK code, 
>>> mostly together with dlfcn.h, but this caused portability problem in 
>>> my testing on some Unix platforms, such as AIX.
>>> So far as I see OpenJDK only makes use of basic POSIX.1-2001 
>>> compatible dynamic library manipulation functions, such as dlopen, 
>>> dlclose, dlsym, dlerr functions, no other extensions found, so is 
>>> link.h still neccessary for current implementation? because link.h 
>>> is not found in the c-POSIX standard headers 
>>> (http://en.wikipedia.org/wiki/C_POSIX_library) and I think this 
>>> removal will be an enhancement for portability, does that make sense?
>>>
>>> Here's the proposed patch, since most parts of it are from Java2d so 
>>> I post it here for discussion.
>>> http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
>>> <http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>
>>>
>>> And one more question, in 
>>> src/solaris/native/sun/java2d/x11/XRBackendNative.c I found 
>>> following comments
>>>  #ifdef __solaris__
>>>  /* Solaris 10 will not have these symbols at runtime */
>>>  #include <link.h>
>>>
>>> And in src/solaris/native/sun/awt/fontpath.c,
>>>  #include <dlfcn.h>
>>>  #ifndef __linux__ /* i.e. is solaris */
>>>  #include <link.h>
>>>  #endif
>>>
>>> I've built successfully on Ubuntu 11.10 32bit and OpenSolaris 
>>> Express 2010.11 x86, the patch seems to be OK, but does anybody know 
>>> the situation on Solaris (e.g. Solaris 10) of this problem?
>>> I assume it will also comply with POSIX.1-2001 standard, and provide 
>>> all the required functions in dlfcn.h, right?
>>>
>>> Cheers!
>>> - Jonathan
>>>
>>
>


From luchsh at linux.vnet.ibm.com  Tue Mar 13 03:21:36 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 13 Mar 2012 18:21:36 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F5DDECB.7080502@oracle.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
Message-ID: <4F5F1FB0.8010805@linux.vnet.ibm.com>

Hi Alan,

With Phil's advice, I've splitted the original patch into two parts and 
created another bug for TL repository, bug 7153343.

And here's the rebased patch based on TL repository.
http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch

Could you please take a look?

Thanks!
- Jonathan


On 03/12/2012 07:32 PM, Alan Bateman wrote:
> On 12/03/2012 02:45, Jonathan Lu wrote:
>>
>> :
>>
>> Here's the proposed patch, since most parts of it are from Java2d so 
>> I post it here for discussion.
>> http://cr.openjdk.java.net/~luchsh/remove_link_h/ 
>> <http://cr.openjdk.java.net/%7Eluchsh/remove_link_h/>
> The change to sun.nio.fs.GnomeFileTypeDetector looks okay to me 
> although you'll need to re-base your patch to jdk8/tl because of the 
> Mac port.
>
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120313/88254deb/attachment.html 

From Alan.Bateman at oracle.com  Tue Mar 13 03:25:58 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Mar 2012 10:25:58 +0000
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F5F1FB0.8010805@linux.vnet.ibm.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com>
Message-ID: <4F5F20B6.1050806@oracle.com>

On 13/03/2012 10:21, Jonathan Lu wrote:
> Hi Alan,
>
> With Phil's advice, I've splitted the original patch into two parts 
> and created another bug for TL repository, bug 7153343.
>
> And here's the rebased patch based on TL repository.
> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>
> Could you please take a look?
It looks okay to me.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120313/b295ac85/attachment.html 

From martin.kirst at s1998.tu-chemnitz.de  Tue Mar 13 13:50:36 2012
From: martin.kirst at s1998.tu-chemnitz.de (Martin Kirst)
Date: Tue, 13 Mar 2012 21:50:36 +0100
Subject: 6341887: Inflater can't handle ByteBuffer
Message-ID: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>

Hi,

I'm interested in contribute some work to openJdk.
I found the Sun BUG:
  6341887 "Inflater.setInput(), Inflater.inflate() can't handle ByteBuffer".

After digging a little in the mailing archives I found nothing.

After successfully building JDK8 from source,
I would like to go ahead and code some patches.

Are there any ideas around?
Pros/Cons?

Regards
  Martin

PS: According to the contribution guideline,
  I'm not asking for support but for some discussion ;-)


From zhong.j.yu at gmail.com  Tue Mar 13 21:21:19 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Tue, 13 Mar 2012 23:21:19 -0500
Subject: 6341887: Inflater can't handle ByteBuffer
In-Reply-To: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
References: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
Message-ID: <CACuKZqFH2G=_TOQtpMHwOUnJQwGRsEWUsSedvCK-S1bfHr5RXQ@mail.gmail.com>

I'd really appreciate that. I wrote a gzip filter in an nio system
with Deflater. Most APIs use ByteBuffer, it's a little odd to have to
convert to/from byte[].

Performance wise, we may need to copy input data from a ByteBuffer to
a byte[], and we definitely need to copy output data byte[] to a
direct ByteBuffer (for socket). But these extra copying doesn't really
matter since Deflater throughput is much slower than memory copying
throughput. Not sure about Inflater though.

Zhong Yu

On Tue, Mar 13, 2012 at 3:50 PM, Martin Kirst
<martin.kirst at s1998.tu-chemnitz.de> wrote:
> Hi,
>
> I'm interested in contribute some work to openJdk.
> I found the Sun BUG:
> ?6341887 "Inflater.setInput(), Inflater.inflate() can't handle ByteBuffer".
>
> After digging a little in the mailing archives I found nothing.
>
> After successfully building JDK8 from source,
> I would like to go ahead and code some patches.
>
> Are there any ideas around?
> Pros/Cons?
>
> Regards
> ?Martin
>
> PS: According to the contribution guideline,
> ?I'm not asking for support but for some discussion ;-)
>

From zhangshj at linux.vnet.ibm.com  Tue Mar 13 21:56:27 2012
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Wed, 14 Mar 2012 12:56:27 +0800
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F5E6502.1030307@oracle.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com>
	<4F5DD311.8070605@oracle.com> <4F5E6502.1030307@oracle.com>
Message-ID: <4F6024FB.2040509@linux.vnet.ibm.com>

On 3/13/2012 5:05 AM, chris hegarty wrote:
> On 12/03/2012 10:42, Alan Bateman wrote:
>> ...
>> 7152948: (dc) DatagramDispatcher.c should memset msghdr to make it
>> portable to other platforms
>>
>> The changes look okay to me but I think might be a bit cleaner to do the
>> memset just prior to setting msg_iov/msg_iovlen (to keep the
>> initialization of the msghdr structure in one place).
>>
>> While you are there, can you change the value 16 to IOV_MAX? (requires
>> limits.h).
>
> Yes, this would be better. I also agree with your previous comment.
>
> I ran some builds and tests on Solaris and Linux with the current 
> patch. All pass fine. I'll do the same when Shi Jun posts an updated 
> patch.
>
> -Chris.
>
>>
>> -Alan
>>
>>
>>
>>
>
Thanks for the review, Alan & Chris.

Here is the new webrev:
http://cr.openjdk.java.net/~zhangshj/7152948/webrev.01/

-- 
Regards,

Shi Jun Zhang



From Alan.Bateman at oracle.com  Wed Mar 14 01:20:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Mar 2012 08:20:31 +0000
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F6024FB.2040509@linux.vnet.ibm.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com>
	<4F5DD311.8070605@oracle.com> <4F5E6502.1030307@oracle.com>
	<4F6024FB.2040509@linux.vnet.ibm.com>
Message-ID: <4F6054CF.1090107@oracle.com>

On 14/03/2012 04:56, Shi Jun Zhang wrote:
> Thanks for the review, Alan & Chris.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~zhangshj/7152948/webrev.01/
>
The updated webrev looks fine to me. Thanks for changing the 16s to IOV_MAX.

Chris - are you going to push this for Shi Jun?

-Alan.

From Alan.Bateman at oracle.com  Wed Mar 14 01:23:47 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Mar 2012 08:23:47 +0000
Subject: 6341887: Inflater can't handle ByteBuffer
In-Reply-To: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
References: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
Message-ID: <4F605593.9000902@oracle.com>

On 13/03/2012 20:50, Martin Kirst wrote:
> Hi,
>
> I'm interested in contribute some work to openJdk.
> I found the Sun BUG:
>  6341887 "Inflater.setInput(), Inflater.inflate() can't handle 
> ByteBuffer".
>
> After digging a little in the mailing archives I found nothing.
>
> After successfully building JDK8 from source,
> I would like to go ahead and code some patches.
>
> Are there any ideas around?
> Pros/Cons?
>
> Regards
>  Martin
>
> PS: According to the contribution guideline,
>  I'm not asking for support but for some discussion ;-)
>
I assume you've read the "How to contribute" page: 
http://openjdk.java.net/contribute/

Otherwise I would go ahead and bring your patch to core-libs-dev. 
Sherman has already added update(ByteBuffer) methods to CRC32 and 
Adler32 but not the Inflater/Deflater classes.

-Alan

From Alan.Bateman at oracle.com  Wed Mar 14 01:24:50 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Mar 2012 08:24:50 +0000
Subject: 6341887: Inflater can't handle ByteBuffer
In-Reply-To: <CACuKZqFH2G=_TOQtpMHwOUnJQwGRsEWUsSedvCK-S1bfHr5RXQ@mail.gmail.com>
References: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
	<CACuKZqFH2G=_TOQtpMHwOUnJQwGRsEWUsSedvCK-S1bfHr5RXQ@mail.gmail.com>
Message-ID: <4F6055D2.9040905@oracle.com>

On 14/03/2012 04:21, Zhong Yu wrote:
> :
>
> Performance wise, we may need to copy input data from a ByteBuffer to
> a byte[], and we definitely need to copy output data byte[] to a
> direct ByteBuffer (for socket). But these extra copying doesn't really
> matter since Deflater throughput is much slower than memory copying
> throughput. Not sure about Inflater though.
If it's a direct buffer there shouldn't be any additional copying when 
using a SocketChannel.

-Alan.



From chris.hegarty at oracle.com  Wed Mar 14 02:11:05 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Mar 2012 09:11:05 +0000
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F6054CF.1090107@oracle.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com>
	<4F5DD311.8070605@oracle.com> <4F5E6502.1030307@oracle.com>
	<4F6024FB.2040509@linux.vnet.ibm.com> <4F6054CF.1090107@oracle.com>
Message-ID: <4F6060A9.4040505@oracle.com>

On 14/03/12 08:20, Alan Bateman wrote:
> On 14/03/2012 04:56, Shi Jun Zhang wrote:
>> Thanks for the review, Alan & Chris.
>>
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~zhangshj/7152948/webrev.01/
>>
> The updated webrev looks fine to me. Thanks for changing the 16s to
> IOV_MAX.

Yes, the updated webrev looks better.

> Chris - are you going to push this for Shi Jun?

Yes, I'll do some builds and tests. Given a positive results I'll push 
this later today.

-Chris.

>
> -Alan.

From chris.hegarty at oracle.com  Wed Mar 14 08:22:05 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Mar 2012 15:22:05 +0000
Subject: RFR: 7152948 msghdr structure not initialized properly in
	DatagramDispatcher
In-Reply-To: <4F6060A9.4040505@oracle.com>
References: <4F5DC30D.2000900@linux.vnet.ibm.com>
	<4F5DD311.8070605@oracle.com> <4F5E6502.1030307@oracle.com>
	<4F6024FB.2040509@linux.vnet.ibm.com>
	<4F6054CF.1090107@oracle.com> <4F6060A9.4040505@oracle.com>
Message-ID: <4F60B79D.5000200@oracle.com>

On 14/03/2012 09:11, Chris Hegarty wrote:
> On 14/03/12 08:20, Alan Bateman wrote:
>> On 14/03/2012 04:56, Shi Jun Zhang wrote:
>>> Thanks for the review, Alan & Chris.
>>>
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~zhangshj/7152948/webrev.01/
>>>
>> The updated webrev looks fine to me. Thanks for changing the 16s to
>> IOV_MAX.
>
> Yes, the updated webrev looks better.
>
>> Chris - are you going to push this for Shi Jun?
>
> Yes, I'll do some builds and tests. Given a positive results I'll push
> this later today.

To close the loop on this.
   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68efc74309f9

-Chris.

>
> -Chris.
>
>>
>> -Alan.

From luchsh at linux.vnet.ibm.com  Thu Mar 15 00:17:23 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 15 Mar 2012 15:17:23 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F5F20B6.1050806@oracle.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
Message-ID: <4F619783.3060308@linux.vnet.ibm.com>

On 03/13/2012 06:25 PM, Alan Bateman wrote:
> On 13/03/2012 10:21, Jonathan Lu wrote:
>> Hi Alan,
>>
>> With Phil's advice, I've splitted the original patch into two parts 
>> and created another bug for TL repository, bug 7153343.
>>
>> And here's the rebased patch based on TL repository.
>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>
>> Could you please take a look?
> It looks okay to me.
>
> -Alan
Thanks Alan!

Can anybody else please help to take a look at the patch?

Regards
- Jonathan Lu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120315/2932b64d/attachment.html 

From chris.hegarty at oracle.com  Thu Mar 15 07:42:15 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Mar 2012 14:42:15 +0000
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F619783.3060308@linux.vnet.ibm.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
	<4F619783.3060308@linux.vnet.ibm.com>
Message-ID: <4F61FFC7.9080802@oracle.com>

On 15/03/12 07:17, Jonathan Lu wrote:
> On 03/13/2012 06:25 PM, Alan Bateman wrote:
>> On 13/03/2012 10:21, Jonathan Lu wrote:
>>> Hi Alan,
>>>
>>> With Phil's advice, I've splitted the original patch into two parts
>>> and created another bug for TL repository, bug 7153343.
>>>
>>> And here's the rebased patch based on TL repository.
>>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>>
>>> Could you please take a look?
>> It looks okay to me.
>>
>> -Alan
> Thanks Alan!
>
> Can anybody else please help to take a look at the patch?

The source changes look fine. I ran some fresh builds and tests, all 
pass fine and no (new) warnings.

I see you are an author for jdk8. Will Charles be pushing this for you, 
or do you want me too?

-Chris.

>
> Regards
> - Jonathan Lu

From luchsh at linux.vnet.ibm.com  Thu Mar 15 19:18:36 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 16 Mar 2012 10:18:36 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F61FFC7.9080802@oracle.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
	<4F619783.3060308@linux.vnet.ibm.com> <4F61FFC7.9080802@oracle.com>
Message-ID: <4F62A2FC.9070408@linux.vnet.ibm.com>

On 03/15/2012 10:42 PM, Chris Hegarty wrote:
> On 15/03/12 07:17, Jonathan Lu wrote:
>> On 03/13/2012 06:25 PM, Alan Bateman wrote:
>>> On 13/03/2012 10:21, Jonathan Lu wrote:
>>>> Hi Alan,
>>>>
>>>> With Phil's advice, I've splitted the original patch into two parts
>>>> and created another bug for TL repository, bug 7153343.
>>>>
>>>> And here's the rebased patch based on TL repository.
>>>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>>>
>>>> Could you please take a look?
>>> It looks okay to me.
>>>
>>> -Alan
>> Thanks Alan!
>>
>> Can anybody else please help to take a look at the patch?
>
> The source changes look fine. I ran some fresh builds and tests, all 
> pass fine and no (new) warnings.
>
> I see you are an author for jdk8. Will Charles be pushing this for 
> you, or do you want me too?
>
> -Chris.
>
>>
>> Regards
>> - Jonathan Lu
Hi Chris,

Thanks for review, I'll ask Charles to help to push the change.

Regards
- Jonathan


From littlee at linux.vnet.ibm.com  Thu Mar 15 19:53:09 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 16 Mar 2012 10:53:09 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F62A2FC.9070408@linux.vnet.ibm.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
	<4F619783.3060308@linux.vnet.ibm.com> <4F61FFC7.9080802@oracle.com>
	<4F62A2FC.9070408@linux.vnet.ibm.com>
Message-ID: <4F62AB15.5030600@linux.vnet.ibm.com>

Hi Jonathan,

The changeset @

Changeset: c4e66dc3222d
Author:    littlee
Date:      2012-03-16 10:47 +0800
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4e66dc3222d

7153343: Dependency on non-POSIX header file<link.h>  causes portability problem
Summary: Remove the unneccessary link.h
Reviewed-by: alanb, chegar
Contributed-by: Jonathan Lu<luchsh at linux.vnet.ibm.com>



Please verify it.


On 03/16/2012 10:18 AM, Jonathan Lu wrote:
> On 03/15/2012 10:42 PM, Chris Hegarty wrote:
>> On 15/03/12 07:17, Jonathan Lu wrote:
>>> On 03/13/2012 06:25 PM, Alan Bateman wrote:
>>>> On 13/03/2012 10:21, Jonathan Lu wrote:
>>>>> Hi Alan,
>>>>>
>>>>> With Phil's advice, I've splitted the original patch into two parts
>>>>> and created another bug for TL repository, bug 7153343.
>>>>>
>>>>> And here's the rebased patch based on TL repository.
>>>>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>>>>
>>>>> Could you please take a look?
>>>> It looks okay to me.
>>>>
>>>> -Alan
>>> Thanks Alan!
>>>
>>> Can anybody else please help to take a look at the patch?
>>
>> The source changes look fine. I ran some fresh builds and tests, all 
>> pass fine and no (new) warnings.
>>
>> I see you are an author for jdk8. Will Charles be pushing this for 
>> you, or do you want me too?
>>
>> -Chris.
>>
>>>
>>> Regards
>>> - Jonathan Lu
> Hi Chris,
>
> Thanks for review, I'll ask Charles to help to push the change.
>
> Regards
> - Jonathan
>


-- 
Yours Charles


From chris.hegarty at oracle.com  Fri Mar 16 03:21:41 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 16 Mar 2012 10:21:41 +0000
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F62AB15.5030600@linux.vnet.ibm.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
	<4F619783.3060308@linux.vnet.ibm.com> <4F61FFC7.9080802@oracle.com>
	<4F62A2FC.9070408@linux.vnet.ibm.com>
	<4F62AB15.5030600@linux.vnet.ibm.com>
Message-ID: <4F631435.4000709@oracle.com>

Charles,

Not a big deal, but since Jonathan is an author for the jdk8 project you 
can create the changeset with his OpenJDK username, then you won't need 
the "Contributed-by" field.

   hg commit -u luchsh ....

Or Jonathan can create the changeset and use 'hg export' to create a 
patch for you to 'hg import'.

-Chris.

On 16/03/2012 02:53, Charles Lee wrote:
> Hi Jonathan,
>
> The changeset @
>
> Changeset: c4e66dc3222d
> Author: littlee
> Date: 2012-03-16 10:47 +0800
> URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4e66dc3222d
>
> 7153343: Dependency on non-POSIX header file<link.h> causes portability
> problem
> Summary: Remove the unneccessary link.h
> Reviewed-by: alanb, chegar
> Contributed-by: Jonathan Lu<luchsh at linux.vnet.ibm.com>
>
>
>
> Please verify it.
>
>
> On 03/16/2012 10:18 AM, Jonathan Lu wrote:
>> On 03/15/2012 10:42 PM, Chris Hegarty wrote:
>>> On 15/03/12 07:17, Jonathan Lu wrote:
>>>> On 03/13/2012 06:25 PM, Alan Bateman wrote:
>>>>> On 13/03/2012 10:21, Jonathan Lu wrote:
>>>>>> Hi Alan,
>>>>>>
>>>>>> With Phil's advice, I've splitted the original patch into two parts
>>>>>> and created another bug for TL repository, bug 7153343.
>>>>>>
>>>>>> And here's the rebased patch based on TL repository.
>>>>>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>>>>>
>>>>>> Could you please take a look?
>>>>> It looks okay to me.
>>>>>
>>>>> -Alan
>>>> Thanks Alan!
>>>>
>>>> Can anybody else please help to take a look at the patch?
>>>
>>> The source changes look fine. I ran some fresh builds and tests, all
>>> pass fine and no (new) warnings.
>>>
>>> I see you are an author for jdk8. Will Charles be pushing this for
>>> you, or do you want me too?
>>>
>>> -Chris.
>>>
>>>>
>>>> Regards
>>>> - Jonathan Lu
>> Hi Chris,
>>
>> Thanks for review, I'll ask Charles to help to push the change.
>>
>> Regards
>> - Jonathan
>>
>
>

From littlee at linux.vnet.ibm.com  Sun Mar 18 19:35:55 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Mon, 19 Mar 2012 10:35:55 +0800
Subject: Fwd: Remove including of link.h to improve portability
In-Reply-To: <4F631435.4000709@oracle.com>
References: <CAC-GWLdkVMSdVKyz=fKEOWWr-s_J+Ye-32XOe5NBedocxYRSOA@mail.gmail.com>
	<4F5D6357.6000400@linux.vnet.ibm.com> <4F5DDECB.7080502@oracle.com>
	<4F5F1FB0.8010805@linux.vnet.ibm.com> <4F5F20B6.1050806@oracle.com>
	<4F619783.3060308@linux.vnet.ibm.com> <4F61FFC7.9080802@oracle.com>
	<4F62A2FC.9070408@linux.vnet.ibm.com>
	<4F62AB15.5030600@linux.vnet.ibm.com> <4F631435.4000709@oracle.com>
Message-ID: <4F669B8B.4000103@linux.vnet.ibm.com>

That's very very helpful.
Thank you very much, Chris.

On 03/16/2012 06:21 PM, Chris Hegarty wrote:
> Charles,
>
> Not a big deal, but since Jonathan is an author for the jdk8 project 
> you can create the changeset with his OpenJDK username, then you won't 
> need the "Contributed-by" field.
>
>   hg commit -u luchsh ....
>
> Or Jonathan can create the changeset and use 'hg export' to create a 
> patch for you to 'hg import'.
>
> -Chris.
>
> On 16/03/2012 02:53, Charles Lee wrote:
>> Hi Jonathan,
>>
>> The changeset @
>>
>> Changeset: c4e66dc3222d
>> Author: littlee
>> Date: 2012-03-16 10:47 +0800
>> URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4e66dc3222d
>>
>> 7153343: Dependency on non-POSIX header file<link.h> causes portability
>> problem
>> Summary: Remove the unneccessary link.h
>> Reviewed-by: alanb, chegar
>> Contributed-by: Jonathan Lu<luchsh at linux.vnet.ibm.com>
>>
>>
>>
>> Please verify it.
>>
>>
>> On 03/16/2012 10:18 AM, Jonathan Lu wrote:
>>> On 03/15/2012 10:42 PM, Chris Hegarty wrote:
>>>> On 15/03/12 07:17, Jonathan Lu wrote:
>>>>> On 03/13/2012 06:25 PM, Alan Bateman wrote:
>>>>>> On 13/03/2012 10:21, Jonathan Lu wrote:
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> With Phil's advice, I've splitted the original patch into two parts
>>>>>>> and created another bug for TL repository, bug 7153343.
>>>>>>>
>>>>>>> And here's the rebased patch based on TL repository.
>>>>>>> http://cr.openjdk.java.net/~luchsh/7153343/jdk.patch
>>>>>>>
>>>>>>> Could you please take a look?
>>>>>> It looks okay to me.
>>>>>>
>>>>>> -Alan
>>>>> Thanks Alan!
>>>>>
>>>>> Can anybody else please help to take a look at the patch?
>>>>
>>>> The source changes look fine. I ran some fresh builds and tests, all
>>>> pass fine and no (new) warnings.
>>>>
>>>> I see you are an author for jdk8. Will Charles be pushing this for
>>>> you, or do you want me too?
>>>>
>>>> -Chris.
>>>>
>>>>>
>>>>> Regards
>>>>> - Jonathan Lu
>>> Hi Chris,
>>>
>>> Thanks for review, I'll ask Charles to help to push the change.
>>>
>>> Regards
>>> - Jonathan
>>>
>>
>>
>


-- 
Yours Charles


From martin.kirst at s1998.tu-chemnitz.de  Mon Mar 19 14:34:33 2012
From: martin.kirst at s1998.tu-chemnitz.de (Martin Kirst)
Date: Mon, 19 Mar 2012 22:34:33 +0100
Subject: 6341887: Inflater can't handle ByteBuffer
In-Reply-To: <4F605593.9000902@oracle.com>
References: <20120313215036.20662qzrlrm29064@mail.tu-chemnitz.de>
	<4F605593.9000902@oracle.com>
Message-ID: <4F67A669.3020501@s1998.tu-chemnitz.de>

Am 14.03.2012 09:23, schrieb Alan Bateman:
> On 13/03/2012 20:50, Martin Kirst wrote:
>> Hi,
>>
>> I'm interested in contribute some work to openJdk.
>> I found the Sun BUG:
>>  6341887 "Inflater.setInput(), Inflater.inflate() can't handle
>> ByteBuffer".
>> [...]
>> PS: According to the contribution guideline,
>>  I'm not asking for support but for some discussion ;-)
>>
> I assume you've read the "How to contribute" page:
> http://openjdk.java.net/contribute/
Yes.

> 
> Otherwise I would go ahead and bring your patch to core-libs-dev.
> Sherman has already added update(ByteBuffer) methods to CRC32 and
> Adler32 but not the Inflater/Deflater classes.

Hi,

I just want to summarize ...
In general it sounds great and I can go ahead ;-)

So I will code something, sign Oracle special agreement
and I will send patches to core-libs-dev mailing list for further
reviews and so on.

Regards
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120319/32705bc2/signature.asc 

From zhong.j.yu at gmail.com  Wed Mar 28 16:34:45 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 28 Mar 2012 18:34:45 -0500
Subject: AsynchronousFileChannel.finalize()?
Message-ID: <CACuKZqG9Bhm_FX5eCxAMK6n2QoneTD7WhjzCF92J3SpYQG2_Zg@mail.gmail.com>

It appears that if close() is not invoked before an
AsynchronousFileChannel becomes unreachable, the file handle remains
open, and we get a resource leak.

We can blame the programer for not properly closing the channel.
However, would the nio team consider to add a feature anyway that will
automatically invoke close() in finalize() (or something like
sun.misc.Cleaner)?

I have a use case where this feature could be helpful. A server has a
file that's constantly requested by clients. The server opens one
AsynchronousFileChannel and caches it. The same channel is used to
serve all client requests to the file. When the server evicts the
channel from the cache, it cannot immediately close() the channel
right away, because the channel could still be referenced by request
processors reading the file. The channel should be closed only after
nobody references it.

The point is that an AsynchronousFileChannel can be shared and
accessed concurrently by multiple users; then it is difficult to
pre-assign a user with the responsibility of closing the channel. It
should be the last user that uses the channel - which is better
handled in JDK.

(In comparison, FileInputStream/FileChannel should have only one user
at any given time, therefore it's clear who is responsible to do the
close(). I wouldn't request the feature on these two classes.)

Zhong Yu

From vitalyd at gmail.com  Wed Mar 28 17:16:45 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 28 Mar 2012 20:16:45 -0400
Subject: AsynchronousFileChannel.finalize()?
In-Reply-To: <CACuKZqG9Bhm_FX5eCxAMK6n2QoneTD7WhjzCF92J3SpYQG2_Zg@mail.gmail.com>
References: <CACuKZqG9Bhm_FX5eCxAMK6n2QoneTD7WhjzCF92J3SpYQG2_Zg@mail.gmail.com>
Message-ID: <CAHjP37EPkzNgoDnSGxOijfnRz-CFzbMHa-yXB-tJPqxyDkTmtQ@mail.gmail.com>

Relying on finalization is far from ideal given its nondeterminism.  It
seems like you may want to have a ref count associated with the channel,
which is checked during eviction.  This will require some bookkeeping and
maybe locking in a few places, which may reduce throughput somewhat, but at
least you'll have full control and deterministic behavior.  Just a thought
...

Sent from my phone
On Mar 28, 2012 7:36 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

> It appears that if close() is not invoked before an
> AsynchronousFileChannel becomes unreachable, the file handle remains
> open, and we get a resource leak.
>
> We can blame the programer for not properly closing the channel.
> However, would the nio team consider to add a feature anyway that will
> automatically invoke close() in finalize() (or something like
> sun.misc.Cleaner)?
>
> I have a use case where this feature could be helpful. A server has a
> file that's constantly requested by clients. The server opens one
> AsynchronousFileChannel and caches it. The same channel is used to
> serve all client requests to the file. When the server evicts the
> channel from the cache, it cannot immediately close() the channel
> right away, because the channel could still be referenced by request
> processors reading the file. The channel should be closed only after
> nobody references it.
>
> The point is that an AsynchronousFileChannel can be shared and
> accessed concurrently by multiple users; then it is difficult to
> pre-assign a user with the responsibility of closing the channel. It
> should be the last user that uses the channel - which is better
> handled in JDK.
>
> (In comparison, FileInputStream/FileChannel should have only one user
> at any given time, therefore it's clear who is responsible to do the
> close(). I wouldn't request the feature on these two classes.)
>
> Zhong Yu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120328/1e6e4731/attachment.html 

From zhong.j.yu at gmail.com  Wed Mar 28 19:40:59 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 28 Mar 2012 21:40:59 -0500
Subject: AsynchronousFileChannel.finalize()?
In-Reply-To: <CAHjP37EPkzNgoDnSGxOijfnRz-CFzbMHa-yXB-tJPqxyDkTmtQ@mail.gmail.com>
References: <CACuKZqG9Bhm_FX5eCxAMK6n2QoneTD7WhjzCF92J3SpYQG2_Zg@mail.gmail.com>
	<CAHjP37EPkzNgoDnSGxOijfnRz-CFzbMHa-yXB-tJPqxyDkTmtQ@mail.gmail.com>
Message-ID: <CACuKZqF5Y75ZGRKncZcVSd7x3+=_85zRS+hznx1E3NgaNBa7rQ@mail.gmail.com>

You are right, we can't wait till GC to close a file; user code has to
trigger close() asap.

In the use case, how much overhead can we really save by using a
shared channel? If instead a new channel is opened for every new
request, the added overhead won't be significant, considering OS
caching, correct? If there's not much advantage to share a channel, my
use case can be simply dismissed.

Zhong Yu

On Wed, Mar 28, 2012 at 7:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Relying on finalization is far from ideal given its nondeterminism.? It
> seems like you may want to have a ref count associated with the channel,
> which is checked during eviction.? This will require some bookkeeping and
> maybe locking in a few places, which may reduce throughput somewhat, but at
> least you'll have full control and deterministic behavior.? Just a thought
> ...
>
> Sent from my phone
>
> On Mar 28, 2012 7:36 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:
>>
>> It appears that if close() is not invoked before an
>> AsynchronousFileChannel becomes unreachable, the file handle remains
>> open, and we get a resource leak.
>>
>> We can blame the programer for not properly closing the channel.
>> However, would the nio team consider to add a feature anyway that will
>> automatically invoke close() in finalize() (or something like
>> sun.misc.Cleaner)?
>>
>> I have a use case where this feature could be helpful. A server has a
>> file that's constantly requested by clients. The server opens one
>> AsynchronousFileChannel and caches it. The same channel is used to
>> serve all client requests to the file. When the server evicts the
>> channel from the cache, it cannot immediately close() the channel
>> right away, because the channel could still be referenced by request
>> processors reading the file. The channel should be closed only after
>> nobody references it.
>>
>> The point is that an AsynchronousFileChannel can be shared and
>> accessed concurrently by multiple users; then it is difficult to
>> pre-assign a user with the responsibility of closing the channel. It
>> should be the last user that uses the channel - which is better
>> handled in JDK.
>>
>> (In comparison, FileInputStream/FileChannel should have only one user
>> at any given time, therefore it's clear who is responsible to do the
>> close(). I wouldn't request the feature on these two classes.)
>>
>> Zhong Yu

From vitalyd at gmail.com  Thu Mar 29 06:00:37 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 29 Mar 2012 09:00:37 -0400
Subject: AsynchronousFileChannel.finalize()?
In-Reply-To: <CACuKZqF5Y75ZGRKncZcVSd7x3+=_85zRS+hznx1E3NgaNBa7rQ@mail.gmail.com>
References: <CACuKZqG9Bhm_FX5eCxAMK6n2QoneTD7WhjzCF92J3SpYQG2_Zg@mail.gmail.com>
	<CAHjP37EPkzNgoDnSGxOijfnRz-CFzbMHa-yXB-tJPqxyDkTmtQ@mail.gmail.com>
	<CACuKZqF5Y75ZGRKncZcVSd7x3+=_85zRS+hznx1E3NgaNBa7rQ@mail.gmail.com>
Message-ID: <CAHjP37FCixd5ypLNyAPDDXFewkfkbcwYzy=yO1xFA2dgkbf+Zw@mail.gmail.com>

Opening a new one per request will create mem churn plus involve a syscall
to open the file (so user --> kernel transition, which isn't cheap,
relatively speaking).  You're right in that the actual i/o workload will
probably not change due to page cache.

I say try out the simplest solution (new channel per request) and monitor
performance; if you see an issue, try a refcounted approach and compare.

Sent from my phone
On Mar 28, 2012 10:40 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

> You are right, we can't wait till GC to close a file; user code has to
> trigger close() asap.
>
> In the use case, how much overhead can we really save by using a
> shared channel? If instead a new channel is opened for every new
> request, the added overhead won't be significant, considering OS
> caching, correct? If there's not much advantage to share a channel, my
> use case can be simply dismissed.
>
> Zhong Yu
>
> On Wed, Mar 28, 2012 at 7:16 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > Relying on finalization is far from ideal given its nondeterminism.  It
> > seems like you may want to have a ref count associated with the channel,
> > which is checked during eviction.  This will require some bookkeeping and
> > maybe locking in a few places, which may reduce throughput somewhat, but
> at
> > least you'll have full control and deterministic behavior.  Just a
> thought
> > ...
> >
> > Sent from my phone
> >
> > On Mar 28, 2012 7:36 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:
> >>
> >> It appears that if close() is not invoked before an
> >> AsynchronousFileChannel becomes unreachable, the file handle remains
> >> open, and we get a resource leak.
> >>
> >> We can blame the programer for not properly closing the channel.
> >> However, would the nio team consider to add a feature anyway that will
> >> automatically invoke close() in finalize() (or something like
> >> sun.misc.Cleaner)?
> >>
> >> I have a use case where this feature could be helpful. A server has a
> >> file that's constantly requested by clients. The server opens one
> >> AsynchronousFileChannel and caches it. The same channel is used to
> >> serve all client requests to the file. When the server evicts the
> >> channel from the cache, it cannot immediately close() the channel
> >> right away, because the channel could still be referenced by request
> >> processors reading the file. The channel should be closed only after
> >> nobody references it.
> >>
> >> The point is that an AsynchronousFileChannel can be shared and
> >> accessed concurrently by multiple users; then it is difficult to
> >> pre-assign a user with the responsibility of closing the channel. It
> >> should be the last user that uses the channel - which is better
> >> handled in JDK.
> >>
> >> (In comparison, FileInputStream/FileChannel should have only one user
> >> at any given time, therefore it's clear who is responsible to do the
> >> close(). I wouldn't request the feature on these two classes.)
> >>
> >> Zhong Yu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120329/c400cf79/attachment.html 

From zhong.j.yu at gmail.com  Fri Mar 30 22:02:18 2012
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Sat, 31 Mar 2012 00:02:18 -0500
Subject: executor for AsynchronousFileChannel.open()
Message-ID: <CACuKZqFPjmBcrPgX=hY7Uf8AHKkVHrRNc8QCkmUi2UEzN8nGJQ@mail.gmail.com>

Hi there,

Suppose I have 100 asyn file channels for reading (concurrently). All
my completion handlers are non-blocking and short. What kind of
executor is best for AsynchronousFileChannel.open()?

My initial choice was a ThreadPoolExecutor with maximumPoolSize==P
where P is the number of processors, because it would be less
efficient to have more than P threads executing non-blocking tasks
(i.e. completion handlers).

However the javadoc of AsynchronousFileChannel.open() states that
there could be other kinds of tasks submitted to the executor, and the
nature of these tasks are unclear. Then I'm lost.

Any advice on an appropriate executor for my specific use case?

Thanks,
Zhong Yu