Thank you for your suggestions. Do you have any old bug in java
deployment for my reference? In addition, I wonder whether the same
language problem exists when calling strerror() function. Thanks!
-Dan
On 03/13/2013 04:10 AM, Alexey Utkin wrote:
On 12.03.2013 3:43, Dan Xu wrote:
Thanks for
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 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 i
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 betwe
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
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 be
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 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)
function, I will log another bug and address
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 07
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]:
http://msdn.microsoft.com/en-gb/library/windows/deskto
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]:
http://ms
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
several
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 al
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 up
On Fri, Feb 1, 2013 at 9:51 AM, Alan Bateman wrote:
> 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 to
> enable close-on-e
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 never
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 de
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 s
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 wrote:
> Hi Karen,
>
> In my opinion, it is recommemde
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
http://www.oracle.co
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 Jan
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 i
_util_md.h, I
did not add JNIEXPORT. I will check whether it can solve the link issue
if I remove JNIEXPORT from the method 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
:
---- Ori
io_util_md.h - it's not obvious to me why
these need JNIEXPORT 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:
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:
25 matches
Mail list logo
