Re: [RFC] sketch of a 'unified cancellation' approach

Alex Rousskov <rousskov_at_measurement-factory.com> writes:
> On 01/31/2013 10:08 AM, Rainer Weikusat wrote:

[...]

>> I spent some time thinking how a 'nicer' cancellation subsystem with all
>> desirable properties (both 'simple to use' and 'efficient to
>> implement' could look like).

[...]

> If you decide to work on this, please use the following plan:

[...]

There are certain limits regarding what I can and can't do. I could
have fixed the original issues (connect timeout not working/ connect
retries not working) within the limits of the exising ConnOpener
because these were relatively simple changes I needed to get done in
any case. I started to do this based on your outline of that from last
September which included the suggestion to use eventAdd for the
connect timeout, something I generally consider to be The Right
Thing[tm] because the connect timeout isn't really associated with any
particular file descriptor. This was essentially killed by you because
of 'performance concerns' regarding the event.cc implementation. But I
still need this working and preferably, with a (relatively) minimal
set of changes from what will eventually become the squid 3.3 release.

I could also have mitigated the linked-list 'performance concerns'
because this is an area where I have some expertise and it basically
required one hour of hacking and four hours of debugging. While I'm
still planning to do a 'bug free' (w/o known bugs) release of that
for the sake of completeness once I get out of the 'other problems
eating me alive state' I'm presently in, it is quite evident that this
is also going nowhere.

I could conceivably even justify putting a nicer interface on top of
that but something I can't do is go onto a (moderately) lengthy 'clean
up the mess other people put into the project' spree, especially for
code I'm neither using nor plan to use: That's of no conceivable use
for the company employing me[*] and most of my so-called 'spare time'
goes into rather mundane tasks such as cleaning, dish washing, cooking
etc. So, this is (despite I'm not entirely uninterested in that,
it really sounds like a nice, little fun project) not going to
happen unless 'the external circumstances' change in some drastic way.

[*] "use the quick-and-dirty solution" could be regarded as the middle
name of the responsible descision person.
Received on Tue Feb 05 2013 - 01:01:05 MST