Re: [PATCH] schedule connect timeouts via eventAdd

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, I am against
replacing one central queue implementation with another in the middle of
a different and urgent project just because it is conjectured that the
other implementation is going to be simple and fast enough, especially
when there are reasons to believe that it cannot be fast enough (because
of the fundamental properties of the problem).

> 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.

Yes, they are. However, removing them would take a lot more than a
different queue implementation. Moreover, implementing ConnOpener
timeouts using events when the rest of the code is using Comm is also
bad design.

Alex.
Received on Thu Jan 24 2013 - 22:20:30 MST