Re: scalable event scheduling

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 31 Jan 2013 09:37:30 -0700

On 01/31/2013 07:21 AM, Rainer Weikusat wrote:
> Alex Rousskov <rousskov_at_measurement-factory.com> writes:
>> There were two primary changes in the patch that Rainer has posted:
>>
>> A) An event queue engine replacement.
>> B) An additional event cancellation API.

> These are not two 'separate, primary changes': One of the features of
> the 'other' data structure is that it enables efficient removal of
> events

Motivation and development plans are often important in understanding
changes, of course, but when deciding what to do with the code, we have
to step back a little from the specific problem the code was attempting
to solve and look at what the code does. When we do that to your patch,
the existence of two distinct changes that can (and IMO should) be
evaluated separately becomes apparent IMO. This view in no way damages
or diminishes your contribution. It just makes it easier to correctly
evaluate it.

The same patch can also be evaluated "as a whole" if the reviewer
prefers that approach, of course.

> [*] Don't assume that everyone you don't yet know must be more-or-less
> a student warily trying his first 'real-world' programming steps.

I have seen no evidence that somebody have assumed the above on these
threads. I certainly have not. Just because somebody thinks there is a
better way to do something (or that something should not be done), does
not mean they think badly of others! And surely, as a seasoned
developer, you know that even programming gurus make mistakes,
especially when dealing with a new-to-them code base.

Setbacks are unavoidable, but you may find the whole process more
rewarding and efficient by accepting that smart, honest, and
well-meaning people can disagree. A disagreement on this list is
virtually never a sign of some kind of ill intent or hidden agenda.
Assuming that (and especially acting on that assumption) only hurts the
process. We are all here to make Squid better, even though that means
different things to different people. And while forking is an important
right, Squid would not exist if it was forked every time an idea or
patch was modified or shot down.

HTH,

Alex.
Received on Thu Jan 31 2013 - 16:37:36 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 31 2013 - 12:00:08 MST