[interfacekit] Re: BHandler::fToken
- From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
- To: "OBOS IK Team" <interfacekit@xxxxxxxxxxxxx>
- Date: Mon, 10 Mar 2003 23:46:07 +0200
> > I've proposed to DarkWyrm to use as a server token a BView pointer,
> > for a faster retrieval of the BView that's gonna receive the message.
>
> I suppose you mean a ServerView(or Layer) pointer?
NO! I mean a BView pointer( more exactly, the address)!
Look down, and you'll find the reason.
> > I don't see
> > how a token received form app_server can be invalid! Once a BView
> > object is instantiated, it has the same address until it's deleted.
> > But before it is deleted, it is detached form the window it belongs,
thus
> > a message is sent
> > to ServerWindow. The Layer that was associated with, is deleted, and the
> > token(the BView's address) is removed from the ServerWindow's
> > list of known
> > tokens.
>
> Actually a ServerView(or Layer) exists as long as the BView is attached to
> a BWindow, once the BView gets detached, the corresponding ServerView is
> deleted. A new one is created when the BView gets attached again.
OK, Isn't that what I've said?
> 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.
Marc, this is TRUE if we use a Layer pointer(address) as a server token!
As I said earlier, I *REALLY* think we should use a BView pointer(address)
as a server token.
Please look down, you'll see what I mean.
Before I begin I'd like to say a few things.
TO DarkWyrm: 1. Is there a need for a Layer to be uniquely identified
through out app_server?
2. Is there a need for a ServerWindow object to
be uniquely
identified through out app_server?
through the following lines when I say 'pointer' what I really mean
is:
'the address at witch it points to'. (an uint32)
Here is a detailed method that I propose for server tokens representation.
(especially BView tokens, because I think BWindow tokens need to be
uniquely identified in app_server)
Why am I proposing this? First, because, it's an alternative to
BView::server_token :-). Second, and here we're done with jokes, for SPEED.
This method, is really fast.
App_server messages concerning BViews are very numerous! For every
message that's meant for a BView, I have to make a search through the
BViews tree. That is really expensive, and there is NO better algorithm for
searching a specified BView!!!
Because of that, I suggested, that, at least in BView's case, we use as a
server token its pointer. That means that in case of BView-Layer association
we should generate server tokens client-side!
That way, when we receive a message that contains a server token, we,
actually do a cast to BView*, witch is MUCH FASTER, and immediately call
the BView's function we need!
If we do it like that, every ServerWindow object should have a hash table,
with the key being BView's pointer, and Layer's pointer as the associated
object. Ingo said that memory overhead for maintaining a hash table per
window would be big compared with a single one for app_server. I totally
disagree. The memory overhead will be the same. Either we have a big
has table maintained for all ServerWindows or we have a lot of small hash
tables for every ServerWindow, the memory overhead will be the same.
PLUS, this is where we AGAIN gain some time(I might say - A LOT),
because we only need to search through a relatively small(!) hash, not the
entire list of Layers that exists on the app_server!
When adding a BView as a child of a BWindow, we actually attach the
pointer in the creation message. When ServerWindow receives this message
it creates a Layer, then adds an entry in the (local)hash table with BView's
pointer being the key, and Layer's pointer being the associated object.
When we detach the BView, we will send a message to ServerWindow
with BView's server token attached, it will search the hash, find the
correct entry, get Layer's pointer(AGAIN, gaining some speed(!),
by avoiding a search in ServerWindow's list of Layers, where, again, no
optimization is possible!), and use it do delete(after other calls have
been made) that object.
So, you see... there are 3(!!!) places where we gain significant speed!!!
I'm sure that I've missed something, but in high lines, this is how I would
like to see the server tokening working.
OK that's it,
bye, guys!
Other related posts:
