On 28 Jan 2015, at 21:24, Alan Bateman wrote:
>
> On 28/01/2015 20:01, Chris Hegarty wrote:
>> Reviving an old code review [1], after further investigation…
>>
>> Pertinent details from previous review:
>> "A socket connection which is returned by ServerSocket.accept() is
>> inherited by a child
On 28/01/2015 20:01, Chris Hegarty wrote:
Reviving an old code review [1], after further investigation…
Pertinent details from previous review:
"A socket connection which is returned by ServerSocket.accept() is
inherited by a child process. The expected behavior is that the socket
connection is
On 28 Jan 2015, at 20:48, Ivan Gerasimov wrote:
> Hi Chris!
>
> I think it's better to pass the last argument to SetHandleInformation as 0
> rather than FALSE.
> This argument is DWORD flag, which is a bit subset of the second argument.
Agreed. I will make the change before pushing.
Thanks,
-
Hi Chris!
I think it's better to pass the last argument to SetHandleInformation as
0 rather than FALSE.
This argument is DWORD flag, which is a bit subset of the second argument.
Sincerely yours,
Ivan
On 28.01.2015 23:01, Chris Hegarty wrote:
Reviving an old code review [1], after further in
Reviving an old code review [1], after further investigation…
Pertinent details from previous review:
"A socket connection which is returned by ServerSocket.accept() is
inherited by a child process. The expected behavior is that the socket
connection is not inherited by the child process. This i
Looks good to me, thanks Rob.
-Chris.
On 28 Jan 2015, at 16:46, Rob McKenna wrote:
> This is a fix to a possible race in the current sctp code. In a nutshell the
> conditional only checks that isaCls is not null. However if isaCls is set by
> one thread and that thread is interrupted before s
Looks good.
Roger
On 1/28/2015 11:46 AM, Rob McKenna wrote:
This is a fix to a possible race in the current sctp code. In a
nutshell the conditional only checks that isaCls is not null. However
if isaCls is set by one thread and that thread is interrupted before
setting isaCtrID, the interrup
This is a fix to a possible race in the current sctp code. In a nutshell
the conditional only checks that isaCls is not null. However if isaCls
is set by one thread and that thread is interrupted before setting
isaCtrID, the interrupting thread will falsely assume that isaCtrID has
been set.
