[interfacekit] Re: BHandler::fToken

  • From: "Marc Flerackers" <mflerackers@xxxxxxxxxx>
  • To: <interfacekit@xxxxxxxxxxxxx>
  • Date: Wed, 12 Mar 2003 20:10:10 +0100

> ... but FIRST!!!
>
> PEOPLE!!!! if you know something about the internals of BeOS,
> SHAREEEEE!
> write a document about them!!! ESPECIALLY if you don't work in
> that area!!!

I would write something if I had the time, but I spent already lots of time
this week just writing these e-mails :). And I rather spend time writing
code :P. Actually I do work on an app_server, but one for MS windows, which
I started more than a year ago now. At the point I joined OpenBeOS, my
app_server was very different from the BeOS R5 one, so I joined the
interface kit to work on controls instead, since that code works unchanged
on windows and BeOS (yup all code is written and run on windows :P). When
progressing, more and more windows code was eliminated, and now 90% of the
code in the libs is OpenBeOS code. The libtranslation for example is 100%
OpenBeOS, as are all translators. Nowadays apps like StyledEdit compile,
build and run on windows. I noticed however that in order to make apps work
the same way, or even just work, you have to mimic the app_server much more
closely then I did, it's from that point I started to do some research on
the R5 app_server.

> I'm relatively new to BeOS, as a matter of a fact, the
> most complicated program that I made under it as just 5(!!!) buttons;
> but I know, in high lines, how things work under the hood, that's why
> I wanted to join this project since the beginning, but I couldn't!
> I stayed and studied BeOS architecture, figured some things
> out, others not, made presumptions, tried to do things like Be did,
> for now to discover that SOMEONE ( I think with experience in
> BeOS area. Marc !?!!) ACTUALLY *KNOW* BeOS internals!!!!!

I don't know the complete internals, I also have to make assumptions, and
I'm never 100% sure. Only now and then I research something thoroughly to
find out how it should work.

> SHARE people SHARE!

I don't have time to write eveything down what I know, and my notes are
scatered around, however if you have a problem with something you can always
ask on the list, that way it also gets some more trafic :).

> > I know, but before we start to optimize, we can look if it's
> needed to do
> > so. As some people on the list already said, and even found out by
> > themselves ;), "Premature optimization is the root of all evil".
>
> Here I don't agree. I think once you have a better method you have to
> implement it!

But I think it's better to see if it has to be optimized in the first place
:).

> > > dispatched to BWindow::ConvertToMessage() who will create
> > > a BMessage then call BWindow::DispatchMessage().
> >
> > It is indeed the event port of BWindow that gets the event messages from
> the
> > app_server, but they arrive as normal flattened BMessages. They are
> > unflattened from the port data using the normal BMessage::Unflatten(char
> > const *) in _CEventPort_::GenerateMessage() called from task_looper().
>
> That's quite strange, since, by sending a BMessage, additional
> data is sent
> (BMessages's). By sending a message(a package of preordered data)
> it will be
> faster. Me and DarkWyrm would like to achieve a minimum of port
> messages, with a minimum of data!

I'll try to look at the 'FOB2' format once I find some time, to see if it's
smaller :).

> > BWindow::ConvertToMessage() is a virtual overridden method
> called from the
> > BLooper methods.
>
> In my implementation of BWindow it looks like this:
>
> BMessage* BWindow::ConvertToMessage(void* raw1, int32 code){
>     BMessage *msg;
>
>         // This is in case we receive a BMessage from another thread or
> application
>     msg   = BLooper::ConvertToMessage( raw1, code );
>     if (msg)
>         return msg;
>
>         // This is in case we receive a message from app_server
>     uint8  *raw;
>     raw   = (uint8*)raw1;
>
>     msg   = new BMessage();
>
>     switch(code){
>         ...
>     }
>     return msg;
> }
>
> Is this not good? It also performs the functions that R5's
> _CEventPort_::GenerateMessage() does.

As far a I know _CEventPort_::GenerateMessage() just reads data, creates a
new BMessage and unflattens it. BWindow::ConvertToMessage first calls
BLooper::ConvertToMessage, if that fails it does pretty much the same as
_CEventPort_::GenerateMessage(). I haven't searched for more detail, though
if you're interested I'll look into it, it could be the locking is different
for example.

> What I would like you to
> remember is that, in task_looper() both ports are checked for
> messages, so there would be a few BMessage calls, a few app_server
> message calls, a few  BMessage calls, a few app_server message
> calls .... for BWindow::ConvertToMessage(...).

I think in task_looper() it first checks if _CEventPort_::GenerateMessage()
has a message, if it has, it adds it to the queue, if not it calls
BLooper::ReadMessageFromPort, and adds that one to the message queue if
there is one returned. That's just the beginning of task_looper(), I'm
afraid I don't have the time today to work it out completely, as it's 20:06
here, so I really have to go home now :).

Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer


Other related posts: