Making RegisterRequest and UnregisterRequest virtual so that they can be over...

Making RegisterRequest and UnregisterRequest virtual so that they can be overriden in derived test classes.
Also making the unique id counter static in order to avoid conflicts with id values handed out from base classes.
Since the id will be used on the other side of automation, it's not enough to make the id generator function overridable.  All request IDs must be unique.

R=amit
BUG=none
TEST=Should be no change.  Run automation tests.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=24212

[amit, 2009-08-24 22:49:57]

lgtm with following suggestions.

http://codereview.chromium.org/174345/diff/1/3
File chrome/browser/automation/automation_resource_message_filter.h (right):

http://codereview.chromium.org/174345/diff/1/3#newcode44
Line 44: return base::subtle::Barrier_AtomicIncrement(&unique_request_id_, 1);
How about base::AtomicRefCountInc from base\atomic_ref_count.h?
AtomicRefCountInc should have been named just AtomicCountInc. I think the subtle
classes are kind of internal.

http://codereview.chromium.org/174345/diff/1/3#newcode102
Line 102: // A unique request id per automation channel.
no longer unique per channel, pl update the comment

http://codereview.chromium.org/174345/diff/1/3#newcode103
Line 103: static int unique_request_id_;
static AutomicRefCount unique_request_id_?

[tommi (sloooow) - chröme, 2009-08-25 02:13:18]

http://codereview.chromium.org/174345/diff/1/3
File chrome/browser/automation/automation_resource_message_filter.h (right):

http://codereview.chromium.org/174345/diff/1/3#newcode44
Line 44: return base::subtle::Barrier_AtomicIncrement(&unique_request_id_, 1);
I did look at that but there are two reasons why I didn't use it:
1) It doesn't return the new incremented value for some reason.
2) The header recommends that it not be used: 
// This is a low level implementation of atomic semantics for reference
// counting.  Please use base/ref_counted.h directly instead.

http://codereview.chromium.org/174345/diff/1/3#newcode102
Line 102: // A unique request id per automation channel.
On 2009/08/24 22:49:57, amit wrote:
> no longer unique per channel, pl update the comment

changed to "// A unique request id per process."

[amit, 2009-08-25 02:16:46]

ok, go ahead with it :)

On Mon, Aug 24, 2009 at 7:13 PM, <tommi@chromium.org> wrote:
>
> http://codereview.chromium.org/174345/diff/1/3
> File chrome/browser/automation/automation_resource_message_filter.h
> (right):
>
> http://codereview.chromium.org/174345/diff/1/3#newcode44
> Line 44: return
> base::subtle::Barrier_AtomicIncrement(&unique_request_id_, 1);
> I did look at that but there are two reasons why I didn't use it:
> 1) It doesn't return the new incremented value for some reason.
> 2) The header recommends that it not be used:
> // This is a low level implementation of atomic semantics for reference
> // counting. =A0Please use base/ref_counted.h directly instead.
>
> http://codereview.chromium.org/174345/diff/1/3#newcode102
> Line 102: // A unique request id per automation channel.
> On 2009/08/24 22:49:57, amit wrote:
>>
>> no longer unique per channel, pl update the comment
>
> changed to "// A unique request id per process."
>
> http://codereview.chromium.org/174345
>