Re: [PATCH] schedule connect timeouts via eventAdd

Alex Rousskov <rousskov_at_measurement-factory.com> writes:
> On 01/24/2013 12:51 PM, Rainer Weikusat wrote:
>
>> linked-list implementation will be good enough because [...]
>> I don't think it should be discarded as
>> 'not good enough' based on assumptions alone.
>
> Why not? If a simple model shows significant overhead, and there are no
> known reasons to doubt that model, why is that not a sufficient
> justification to try alternatives that have lower overhead?

Sorry, but I kind-of don't understand what you're up to, at least not
insofar it could be regarded as a technical goal. 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. Also in my opinion (and apparently according the opinion of
someone who wrote a couple of comments a la

    /* TODO: remove these fd_table accesses. But old code still depends on fd_table flags to
     * indicate the state of a raw fd object being passed around.
     * Also, legacy code still depends on comm_local_port() with no access to Comm::Connection
     * when those are done comm_local_port can become one of our member functions to do the below.
     */
) 'these fd_table accesses' are a really bad idea from a design
standpoint. Especially for the connect timeout, where wouldn't be only
'these accesses' to the one table slot but actually moving data
between table slots in some way no one who isn't already familiar with
the code (or who hasn't seen it for long enough to forget the details)
can predict in various locations in a 370 lines file, with the
fd_table variable being a 'global variable' defined in a different
file.

OTOH, it is completely up to you what you want to spend your time on
(which includes implementing alternate approaches for existing code
because of problems I don't believe to be serious in a way I consider
ill thought out) and I don't even really care about the squid code
except insofar it is buggy in ways which affect me. And then, there's
- of course - still my boss who will consider these complete 'going
nowhere' discussion a gigantic waste of time, considering that WE
(meaning, the company I work for) have a working solution for our
problem I (being the relevant person in this particular case) consider
sensible. So, please do whatever pleases you and if the results happen
to be useful for 'me' (again meaning the company I work for), I'll
gladly use them. If not, I'll replace them.

    
     
Received on Thu Jan 24 2013 - 21:47:02 MST