[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Tue, 11 Mar 2003 20:34:08 +0100 (MET)
On Mon, 10 Mar 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > BTW, that reminds me of our BTokenSpace, which reuses tokens of
> > deleted
> > objects. Hence the following situation can occur: A BHandler is
> > created
> > and added to a looper. A BMessenger referring to the handler is
> > created.
> > The handler is removed from the looper and deleted. The next handler
> > will
> > be created with the same token, and therefore the formerly
> > constructed
> > messenger will now address another handler (when being added to the
> > same
> > looper). This is not *that* bad, but the effects may nevertheless be
> > undesirable.
>
> I would consider this as bad, because the new handler would get
> messages that it shouldn't get.
>
> > As a solution I would get rid of the stack collecting tokens of
> > deleted
> > objects and let NewToken() always return a new token. For the quite
> > unlikely case, that the token counter hits the maximum, it should
> > restart
> > from 0 again and set a flag, that from then on NewToken() must first
> > check
>
> Although I would consider 32-bit as enough for this time (if any
> application used all 4 billion IDs, it deserves to die ;-)), but we
> could as well just use 64-bit values and consider us in a safe place.
Yep. And with 64 bit architecture that doesn't introduce any additional
costs (well, a bit of memory, of course ;-).
> Of course, using Ingo's method would also work nicely, and since we
> also have to be binary compatible with R5, this should be the best
> solution :-)
Tokens never appear `on the surface'. And since all concerned classes
(BHandler, BMessage, BMessenger) still have reserved space, we could
actually switch to 64 bit without breaking binary compatibility.
CU, Ingo
Other related posts:
