[interfacekit] Re: Port Messaging

Hello Ithamar,
>>As Dianne said recently most messaing to the app=5Fserver is
>>not BMEssage based, however.  Though you'd entitled to answer
>>by pointing out that this paprticular kind of message (CREATE=5FAPP)
>>is not a bottleneck/CPU-intensive one.
>
>The problem is not bottleneck/CPU-intensivety,

In the quoted example, that is entirely correct. There won't
be more than (lousy random evaluation follows: ) say 10
application creations per second on a busy user day, to compare
with the thousands and thousands of drawing primitives
sent per millisecond to the app_server in peak BRegion refreshing usage.


> but more the fact that 
>app=5Fserver can't (or at least isn't) linked to libbe.so, so that 
>BMessage and friends is not available to it. Dianne also mentioned that 

>the app=5Fserver has a "private" version of BMessage for actually doing 

>some BMessage-related stuff.

We could do otherwise (link) if needed I guess; OK, the problem
I've seen with hacking on all that stuff is that by just linking
to libbe.so it automatically creates  a port for your app (?! what
the hey? maybe there's a static global object in there whose
constructor calls create_port()?), but since OBOS has the much
more resonable stance these days of doing side by side
libopenbe.so and app_server, and thus come up with a
different communication protocol, it leaves all liberty to also
not duplicate that behaviour and this weird global var or whatever.
(and thus ensure that app_server will always create its
"main listener" port id at #0 if this is critical).

One reason using libbe.so would be awfully useful, far as I
can see as of today (with very limited functionality in my "hack"
yet, but still) is to benefit from BRegion: how the app_server
does w/o this class is a mystery to me; maybe they've duplicated
the routines... This has to be the most critical bottleneck
class I've encountered so far in my "hacking" sessions.

--
http://cdegea.free.fr/ | BeDev E-16870
"One thing to rule them all" -- UserFriendly.org, 20011021

Other related posts: