Re: [PATCH] schedule connect timeouts via eventAdd

On 25/01/2013 12:05 p.m., Rainer Weikusat wrote:
> Rainer Weikusat <rw_at_sapphire.mobileactivedefense.com> writes:
>> Alex Rousskov <rousskov_at_measurement-factory.com> writes:
>>> On 01/24/2013 02:46 PM, Rainer Weikusat wrote:
>>>
>>>> In my opinion, using
>>>> a more sensibly priority queue algorithm (still both extremely simple
>>>> to implement and 'readily available' in a canned form), insofar the
>>>> deficiencies of the simple one become actually relevant, makes a lot more
>>>> sense than devising special-case 'workarounds' for these deficiencies
>>>> because it is conjectured that they *might* otherwise become
>>>> relevant.
>>> I am all for using better queuing algorithms. However,
>> [...]
>>
>> And I'm all for getting some actual work done instead of this
>> completely pointless discussion.
> In case this wasn't clear enough: I'm convinced you're heading down
> the wrong road. This conviction may in itself be wrong in some
> absolute sense, however, at the moment, I don't think so, and I
> cannot possibly justify spending more time argueing back and forth
> about it (and wouldn't want to if I could).

Agreed. To cut this all short. I was under the impression that we had
proven the usefulness of add-and-remove model.
Under the current code that 'remove' would be an event delete ("good
enough for now") with possibilities for some future improvement outside
the scope of this change.

So, with maintainer hat on please do the changes necessary to perform
add-and-remove cleanly for timeout events. *If* possible using the
event*() API instead of raw FD table access.

That should be enough to cleanup the timeout problems.

As for connect_retries. It does need some fixes under the new model for
ConnOpener. But that can be a separate patch project and will be
isolated to the Delayed*() callback.

Amos
Received on Thu Jan 24 2013 - 23:38:17 MST