[interfacekit] Re: BHandler::fToken
- From: "Marc Flerackers" <mflerackers@xxxxxxxxxx>
- To: <interfacekit@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2003 09:58:27 +0100
> 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?
It looks like that yes, maybe for security, maybe a leftover from old times.
> 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.
As Cedric Degea pointed out, commands aren't directly written to the port.
They are cached in the _BSession_ (or PortLink in OpenBeOS, both work mostly
in the same way, except that the first one writes it's data into a buffer
and bumps a pointer, while the second one allocates a new buffer, writes the
data and puts the buffer pointer in a list).
The buffer is flushed at several occasions, for example when a command is
sent from which you expect a reply (get_high_color). The buffer is sent
through the port (synced/flushed), and the requested data is read from the
port. So the set_current_view is just an 8 byte command written to the
buffer. I'll still give a small example to illustrate:
---------------------
|4: set current view|
|4: server_token |
---------------------
|4: set high color |
|4: color |
---------------------
|4: move pen to |
|8: x, y |
---------------------
|4: stroke line to |
|8: x, y |
---------------------
without a set_current_view command you would have to add the view token to
every command, which gives quite some extra port trafic. Now you just select
the receiver view for the next commands which follow until the next
set_current_view command.
> 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.
not only that, if you have one big hashtable you can store extra data
besides the pointer, like type and owner information. Especially the last
one is interesting to clean up after an app/thread was killed, as you can
querry all objects that belonged to the app/thread.
Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer
Other related posts:
