Re: [PATCH] StoreID latest implementation in sync with rev 12552. stage 2-3 from 3.

Thanks Alex,

On 1/3/2013 6:23 PM, Alex Rousskov wrote:
> One of the reasons is that sooner or later the current or updated code
> will crash while "accessing the request in these situations". Just
> because you have carefully identified when the request should or should
> not be used now, does not mean that your identification will remain
> valid a year from now or that nobody will copy your code to a different
> location where it will break next week.

Well I can't be responsible for the wind in Taiwan while I'm here.
Sorry.(there is more to come..)
If there will be a change with such a huge impact a basic runtime test
should find that so allow me to doubt a bit.

>
> This has nothing to do with object orientedness. This is about giving a
> correct way of accessing information that may be present in two
> different places, one of which may be invalid. If testing request for
> being nil is sufficient, this is a simple change. If it is not
> sufficient because request may be non-nil but invalid, then it is
> probably too dangerous to commit this code and more work is needed to
> make it reliable (which may include changing other code, of course).

OK got you now.
I need to rephrase something:
There are places in Squid code (not related to my code) which the code
scope allows access to an invalid request.(it's like saying a kid poops)
Leave these aside and while researching the code my main effort was to
back-trace couple functions from runtime back to the request creation.
This research provided me with enough knowledge about the code which
makes this patch code Stable in many aspects.
One of these aspects is not accessing(r\w) what and when not needed at all.

I choose by hand with a needle the specific points of code which sets
and gets data in the main components which affect the identifiers of the
requests while considering the scopes of the code carefully.
If someone will not do the same research as I did and will not have the
right knowledge about the scope which he works on he'd better take a
couple days to read\try and understand what he is working on.
This is how much this patch is good.
(This is the 7th version of a stable working storID)

The code I wrote should not cause any problem such as miss-assertion.

For now only one place in the whole software sets the needed variables
while Any other access to the variables should only be done strictly for
reading with the exception of ICAP\ECAP later on (or before..in runtime).
This is one of the variables that just out there.. public which by
definition should be set only in two places and no where else!!!
The reason for that is since most of the code that doesn't need it don't
have public access to it.
This is how simple it is.

Maybe I can't see the wider picture now and I am sorry for that.
The thing is that the amount of code I was learning and researching was
A lot..
There for I can tell that if a request is invalid and cannot be accessed
while needed I am confidence that you would have seen a Squid without
ink and lifeless long time before my code:D

Thanks again,
Eliezer
Received on Thu Jan 03 2013 - 18:10:37 MST