I'm OK with this as it, but here are a few comments:
The logic around the initial setting of the timeout seems a little
unnecessary (and the additional pointer), but not wrong.
The comments should also be updated.
Given this problem should the build be setting USE_SELECT?
-Chris.
On
On 24/01/12 10:23, Chris Hegarty wrote:
I'm OK with this as it, but here are a few comments:
The logic around the initial setting of the timeout seems a little
unnecessary (and the additional pointer), but not wrong.
Chris,
The setting of the timeval could be combined ok, but I wanted to
Thanks the explanations. As I said, I'm fine with the change as is.
-Chris.
On 01/24/12 10:41 AM, Michael McMahon wrote:
On 24/01/12 10:23, Chris Hegarty wrote:
I'm OK with this as it, but here are a few comments:
The logic around the initial setting of the timeout seems a little
unnecessary
On 23/01/2012 22:32, Michael McMahon wrote:
No, I don't think so. fd_sets are bit masks and you have to specify
the highest numbered bit in the
mask (+1).
Sorry, I wasn't thinking, it's nfds+1.
In that case, I think the change is okay although having t, t1, and t1_p
looks a bit messy. It
On 24/01/12 10:46, Alan Bateman wrote:
On 23/01/2012 22:32, Michael McMahon wrote:
No, I don't think so. fd_sets are bit masks and you have to specify
the highest numbered bit in the
mask (+1).
Sorry, I wasn't thinking, it's nfds+1.
In that case, I think the change is okay although having t,
On 24/01/2012 11:19, Michael McMahon wrote:
Ok, I've updated the webrev to do the above and to adjust the comments
http://cr.openjdk.java.net/~michaelm/7131399/webrev.2/
This looks much cleaner. I'd probably use tp = NULL myself but what you
have is okay.
-Alan
On Mon, Jan 23, 2012 at 7:09 PM, Michael McMahon
michael.x.mcma...@oracle.com wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~**michaelm/7131399/webrev.1/http://cr.openjdk.java.net/%7Emichaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to
On 24/01/12 11:27, Damjan Jovanovic wrote:
On Mon, Jan 23, 2012 at 7:09 PM, Michael McMahon
michael.x.mcma...@oracle.com mailto:michael.x.mcma...@oracle.com
wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
On 24/01/2012 11:47, Michael McMahon wrote:
Damjan,
We can only deal with a finite number of file descriptors already in
this file, although the actual
value can be set as high as required through setrlimit(). getFdEntry()
checks that the fd number
is within the particular limits and all I/O
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge case
tested by JCK,
namely, when a zero length UDP message is sent on a DatagramSocket. The
problem is only
detected on
On 23/01/12 17:09, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge
case tested by JCK,
namely, when a zero length UDP message is sent on a
On 23/01/2012 17:09, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge
case tested by JCK,
namely, when a zero length UDP message is sent on a
On 23/01/12 21:30, Alan Bateman wrote:
On 23/01/2012 17:09, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge
case tested by JCK,
namely, when a
13 matches
Mail list logo
