[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Tue, 11 Mar 2003 20:27:13 +0100 (MET)
On Mon, 10 Mar 2003, Axel =?iso-8859-1?q?D=F6rfler ?= wrote:
>
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > When a BView is created, and attached to a window, a command is
> > > send, and a
> > > server=5Ftoken is returned, this token is then used to control the
> > > ServerView.
> > > In this case the server=5Ftoken is not sent with every command, but a
> > > set=5Fcurrent=5Fview 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=5Fcurrent=5Fview command should outweigh the additional overhead for
> > copying of hundreds of tokens.
>
> They shouldn't matter much, that's right - but of course, everything
> adds up, so saving some copies could also save some time :-)
> But sending additional data should be always cheaper than managing
> another structure on the client-side.
> But I would probably try to use shared memory for the IPC - as long as
> the kernel doesn't provide that feature built-in. We could do the same
> for big BMessages as well.
> Of course, we could also just add this feature to the kernel as well -
> but it should be controllable by the applications involved (so a user-
> space implementation would also make sense [if it would be in a library
> usable by everyone]).
Sounds nice. In any case, care must be taken. Shared memory also means,
that the application has full access; so, if running amok, it may
overwrite important data of other apps's (or in worst case, the kernel's)
ports.
CU, Ingo
Other related posts:
