On 01/17/2013 02:53 PM, Rainer Weikusat wrote:
> Alex Rousskov <rousskov_at_measurement-factory.com> writes:
>> On 01/17/2013 10:56 AM, Rainer Weikusat wrote:
> Then, the ::connect
> method (or some code running on behalf of that) would close
> temporaryFd_ before scheduling a 'delayed connect retry' which would
> open a new socket. A ::timeout running then won't need to free
> write_data and won't have to cancel the early_abort call.
Agreed.
> If the write handler was scheduled
> by the time timout runs, this happened because 'something definite' is
> known about the state of the connection attempt: Either, it suceeded
> or the OS returned an error. Throwing this 'real information' away in
> order to save a line of code seems not right to me even if it is a
> fringe case of a fringe case.
As I said, one would not be just saving lines of code. One would be most
likely introducing bugs (that is exactly what happened in the past with
this code). We have at most two "real information" pieces: a timeout and
I/O status. The first to get to ConnOpener wins.
HTH,
Alex.
Received on Fri Jan 18 2013 - 01:51:26 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 19 2013 - 12:00:09 MST