[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Mon, 10 Mar 2003 17:00:35 +0100 (MET)
On Mon, 10 Mar 2003, Marc Flerackers wrote:
> Why would they be invalid, well, lets say a developer overwrites the memory
> in a wrong place, like BView::server_token, this would cause a wrong token
> to be sent to the server. So to keep the server from crashing in such case,
> it looks up the token to see if it's valid. No one keeps you from storing
> the pointer as a key in the hash table. As long as your keys are unique you
> can use any value you prefer.
> The only point I see with using pointers is that a new object can get the
> same address as one that was deleted previously, which can cause problems
> since an invalid reference could be seen as a valid one. This could make a
> mess in a multithreaded environment.
That's a good argument.
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.
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
whether the token is not already used. Since the token space will be used
sparsely, this should be acceptably performant. BTW, it may be a good idea
to use a hash map instead of a simple map.
CU, Ingo
Other related posts:
