[interfacekit] Re: BHandler::fToken

On Wed, 12 Mar 2003, Marc Flerackers wrote:

>  > > It is indeed the event port of BWindow that gets the event
> > messages from the
> > > app_server, but they arrive as normal flattened BMessages.
> >
> > I'm curious: Do you know any reason for using flattened BMessages? AFAIK
> > (unlike ours) the R5 app server is not linked against libbe and therefore
> > has to do similar hackery as the kernel to produce those. I would
> > understand this, if the messages were sent to the looper port directly.
> > Any reason for not doing this, BTW?
>
> Why would it contain hackery, why not just a copy of the BMessage class,
> without unneeded functionality? This reduces the amount of code to write on
> both sides, and reduces the amount of possible bugs :).

Well, I was exaggerating a bit. :-)
Basically you have the same option in the app server as in the kernel.
Either you create the flattened messages manually, or you clone the
BMessage class.

BTW, the work to strip BMessage (and probably also BMessenger) of
undesired functionality should not be underestimated. E.g. it deals with
quite a bunch of other classes and structures. And as always, cloning code
is not exactly desirable, anyway.

But however, as mentioned, our app server links against libopenbeos and
can use BMessage directly. :-)

> Besides flattened
> messages are not such a bad thing, the amount of overhead it would cause is
> highly exaggerated I think.
> For window/view communication a whole other command based system exists, and
> there I find it justified. But for things that arrive as message, and will
> be handled as a message, I think BMessage should be used, unless testing
> shows it's a bottleneck.

Agreed.

> The app_server messages that arrive on the event port have as magic 'FOB1',
> which shows they're  normal flattened BMessages.

Never doubted, you were wrong. ;-)

> > I wondered, how BView/BWindow could get the token of a BHandler, since
> > neither is a friend of it, but it seems I overlooked the inline friend
> > function `int32 _get_object_token_(const BHandler* )'. BTW, I'd propose to
> > drop all current friends and introduce a single friend class
> > BHandler::Private (similar to BRoster::Private), which bundles the
> > private member access.
>
> As long as we can maintain binary compatibility I see no problem with such
> change. Otherwise we can wait until after R1. I think there's quite some API
> cleanup needed once we have an R1.

Yep, I only mentioned that, because changing it now, before everyone uses
it, would safe us work later.

> > > I find this way of working very clean, and especially safe. As
> > you can see,
> > > only once the view was searched through the tree, and the message went
> > > through the same processing pipeline as all other messages.
> >
> > That clears things up quite a bit. The only thing I don't understand, is
> > why the message isn't sent to the looper port directly. Mmh, now I think
> > about it, is it maybe because the order of other commands sent to the
> > window and the messages must remain the same?
>
> When you use two ports it's easier to give one message priority over the
> other. First you process the event port, then the looper port. Also the
> server window is never blocked when writing to the port, since no-one else
> writes to it.

OK, that would be a reason.

> > Moreover I still wonder, whether the server token for views is really
> > needed (i.e. internally in the app server). A server app local hash table
> > or a global one with a key including an app ID would be fine as well.
>
> Since all resources created on the app_server are identified with server
> tokens it would be strange to use another system for views.

Right. I was just playing a bit with options. :-P

> I also think all
> server tokens are in one global hash table, to allow for cleanup when an app
> crashes.

I don't get that argument. Aren't all app server resources related to a
certain application associated with the respective ServerApp? So cleaning
up would be in any case involve nothing more than deleting the ServerApp
(or somehing like that -- don't know, how it is currently implemented).

> A server token is pretty much like a handle in MS Windows.

*shudder* ;-)

CU, Ingo

Other related posts: