On 12/03/2013 22:19, Dan Xu wrote:
I understand now. Here is the updated webrev to directly map IO_Append
to handleWrite in *nix platforms,
http://cr.openjdk.java.net/~dxu/8001334/webrev.03/.
I checked FileOutputStream.java source code, and we do guarantee the
consistency of append flag
On 12.03.2013 3:43, Dan Xu wrote:
Thanks for all your comments. I have updated the fix accordingly.
Please see the webrev at
http://cr.openjdk.java.net/~dxu/8001334/webrev.02/.
For the language concern in getLastErrorString(char *buf, size_t len)
function, I will log another bug and address
Thank you for the review. I will push it today.
-Dan
On 03/13/2013 03:39 AM, Alan Bateman wrote:
On 12/03/2013 22:19, Dan Xu wrote:
I understand now. Here is the updated webrev to directly map
IO_Append to handleWrite in *nix platforms,
http://cr.openjdk.java.net/~dxu/8001334/webrev.03/.
I
On 03/12/2013 08:19 AM, Alan Bateman wrote:
On 11/03/2013 23:43, Dan Xu wrote:
Thanks for all your comments. I have updated the fix accordingly.
Please see the webrev at
http://cr.openjdk.java.net/~dxu/8001334/webrev.02/.
For the language concern in getLastErrorString(char *buf, size_t len)
On 12/03/2013 18:01, Dan Xu wrote:
Hi Alan,
Do you mean directly map IO_Append to handleWrite in io_util_md.h for
the *nix case? And then where do we check the O_APPEND flag in our
code? Or do we require users to open the file with O_APPEND flag? Thanks!
Yes, either IO_Append is defined to
I understand now. Here is the updated webrev to directly map IO_Append
to handleWrite in *nix platforms,
http://cr.openjdk.java.net/~dxu/8001334/webrev.03/.
I checked FileOutputStream.java source code, and we do guarantee the
consistency of append flag between open and write operations.
Thanks for all your comments. I have updated the fix accordingly.
Please see the webrev at
http://cr.openjdk.java.net/~dxu/8001334/webrev.02/.
For the language concern in getLastErrorString(char *buf, size_t len)
function, I will log another bug and address it later. Thanks!
-Dan
On Thu
On 05/03/2013 18:39, Dan Xu wrote:
Hi All,
Thanks for your good suggestions. I have updated this fix and put the
new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/.
Please help review it. Thanks!
-Dan
I've looked at the latest webrev and it looks quite good. There are
On 07/03/2013 13:21, Alexey Utkin wrote:
Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
getLastErrorString(char *buf, size_t len)
Here is the documentation for [FormatMessage]:
Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
getLastErrorString(char *buf, size_t len)
Here is the documentation for [FormatMessage]:
Hi All,
Thanks for your good suggestions. I have updated this fix and put the
new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. Please
help review it. Thanks!
-Dan
On 02/01/2013 01:25 PM, Alan Bateman wrote:
On 01/02/2013 18:12, Martin Buchholz wrote:
:
My comments are
On 01/02/2013 02:23, Martin Buchholz wrote:
You could operate in paranoid mode and do *both* : use O_CLOEXEC and use
fcntl to set the bit after creating it, perhaps after verifying via fcntl
whether the bit was successfully set by open.
Martin
Alternatively, just leave this code out. We open
Yes, the current Process code deals fairly well with other people's file
descriptors that are not close-on-exec. But this code is brittle, and
long-term it would be cleaner for all open's in the jdk to use O_CLOEXEC by
default. We can probably never remove the Process code that closes all
file
On 01/02/2013 17:45, Martin Buchholz wrote:
Yes, the current Process code deals fairly well with other people's
file descriptors that are not close-on-exec. But this code is
brittle, and long-term it would be cleaner for all open's in the jdk
to use O_CLOEXEC by default. We can probably
On Fri, Feb 1, 2013 at 9:51 AM, Alan Bateman alan.bate...@oracle.comwrote:
There are lots of places in the JDK that open files or sockets, java.iois
just one. It may be better if we separate this from Dan's clean-up and
decide (as part of a separate piece of work) whether we want everywhere
On 01/02/2013 18:12, Martin Buchholz wrote:
:
My comments are all very high level.
The history of generic C-level infrastructure in the JDK is
unsuccessful. The JVM_ functions were apparently a failure, but who
is willing to own the problem of a suitable replacement? Leaving the
problem
Dan,
I had a question on this comment.
Should we fix this in hotspot?
So you mention recent Linux open() documentation.
How does this behave on Solaris and Mac? I assume the library code is shared
code across platforms.
Also - what is the oldest Linux we support for JDK8?
thanks,
Karen
On
Hi Karen,
In my opinion, it is recommemded to use O_CLOEXEC flag directly in
open() function than setting it later via fcntl(). And according to the
man page on Solaris and Mac, open() behaves the same on those platforms.
I only find the support platform list for jdk7 at
You could operate in paranoid mode and do *both* : use O_CLOEXEC and use
fcntl to set the bit after creating it, perhaps after verifying via fcntl
whether the bit was successfully set by open.
Martin
On Thu, Jan 31, 2013 at 12:07 PM, Dan Xu dan...@oracle.com wrote:
Hi Karen,
In my opinion,
On 28/01/2013 19:02, Dan Xu wrote:
These two .obj are needed during the link process in windows platform.
Because getLastErrorString functions, used in io_util.c, are inside
io_util_md.obj. And after adding io_util_md.obj, it also introduces
another dependency on getPrefixed function which is
signature.
That's all I have. I assume you will run all tests on all platforms
before this is pushed.\
Sure, I will run it.
Thanks,
-Dan
-Alan
:
Original Message
Subject: Review Request: JDK-8001334 - Remove use of JVM_*
functions from java.io code
Date: Mon
but this might be tied into my first question about
the make changes.
That's all I have. I assume you will run all tests on all platforms
before this is pushed.
-Alan
:
Original Message
Subject: Review Request: JDK-8001334 - Remove use of JVM_*
functions from java.io code
Moving to core-libs-dev to allow for wider review. As Dan mentions,
we've been looking to remove the Solairs-specific interruptible I/O for
a long time.
Original Message
Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions
from java.io code
Date: Mon
23 matches
Mail list logo
