[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Mon, 10 Mar 2003 16:33:24 +0100 (MET)
On Mon, 10 Mar 2003, Marc Flerackers wrote:
>
> > 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.
Now, reading it again, I have to admit, that my question really sounds
like `What are tokens?'. Sorry, my bad. I actually just wanted to know,
for which operations/interactions the tokens are used, and what this means
regarding their scope. Fortunately your reply is quite comprehensive, so
this is basically answered, too. :-)
> 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).
So, if I understand you correctly the window's token is not really needed,
since all requests (save the window creation request certainly) are sent
through the window's port. Is that true also for window deletion?
> 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.
Mmh, I wonder whether 4 bytes for the token would be of any significance.
At least performance-wise the, at least two, syscalls to deliver the
set_current_view command should outweigh the additional overhead for
copying of hundreds of tokens.
> 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.
That makes sense. The administration/memory overhead for maintaining a
hash table per window would probably be relatively big compared with a
single one for the whole app server.
CU, Ingo
Other related posts:
