[interfacekit] Re: BHandler::fToken
- From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Mon, 10 Mar 2003 15:37:52 +0200
> 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.
Until here, I agree with you.
But with the following paragraph, I don't!
> 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.
A Layer's( BView's counterpart in app_server) token must be unique within
app_server!!!; or, at least, in ServerWindow - that is until DarkWyrm tells
us how it's gonna be.
> 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.
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 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.
Other related posts:
