[interfacekit] Re: BHandler::fToken
- From: "Marc Flerackers" <mflerackers@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Mon, 10 Mar 2003 11:27:46 +0100
> I don't know much about the app server in this respect, though. Maybe
> someone (DarkWyrm :-) can shed some light on what the tokens are needed
> for, anyway.
>
> CU, Ingo
>
This is how it works on BeOS, but I suppose our app_server works in a
similar way.
The client-side tokens are only used for messaging. every message target is
determined by a port (of the looper it belongs to), and a token. This token
only has a meaning within the looper it belongs to. However since a handler
can switch looper (like a view for instance), these tokens should be unique
within the application.
The server_tokens are used to identify server objects. When a BWindow is
created, a request is sent to the server, and a server_token is returned.
These requests are not send with BMessages, but directly written/read
to/from a port using _BSession_. A command id, together with the
server_token token (and additional data if needed) is sent to the server to
show/hide or do other things with the ServerWindow (which may sound strange,
as the BWindow sends this data to the ServerWindow by a port, so the token
is not really needed for delegation).
When a BView is created, and attached to a window, a command is send, and a
server_token is returned, this token is then used to control the ServerView.
In this case the server_token is not sent with every command, but a
set_current_view command is sent if the view which we are going to work with
changes (on the client-side BWindow->fLastViewToken, keeps the current
view), this reduces command size overhead.
Since ServerViews are completely bound to their ServerWindow (since they are
created/deleted when the client side BView is attached/Detached), the tokens
for these don't need to be unique, however it seems that the tokens come
from one big pool on the server-side.
For the people who are new to tokens. You use tokens instead of pointer to
objects because of safety. With a pointer you don't know if the object is
valid. Tokens sit in a hashtable, and are inserted and removed when the
object they point to gets created/deleted. So when you look up a token, you
know you have a valid object.
Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer
Other related posts:
