“There is an unfortunate holdover in the BeOS API which has been depricated in the next version of Zeta: BLooper::PostMessage(). This method has a few special cases which make it dangerous to play with, at least one of which is detailed in the BeBook’s entry for it. But judging from numerous bits of code I have seen, no one really reads the BeBook that closely anyway.” Read the dev article here. Update: Ex-Be engineer Dianne Hackborn replied to the topic.
Send Messages in a Post PostMessage() API
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Bit of a blooper, that one, eh? 😉
It’s good to see these BeOS development articles posted here, Eugenia. It may stir up some interest in development on BeOS/Zeta. At the least it shows the community here that development on the Be platform is still going strong.
Brennan
While i’m not familiar with the reasons in the bebook that one should not use PostMessage, I would’ve assumed that the author would say WHY someone wouldn’t want to use it. If the bebook lists one, why not share it, as well as the others that are unknown. That seems like a pretty reasonable request i think.
If am not mistaken, the reasons are described here:
http://www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/Iss…
Scroll all the way down to “3 — ARE YOUR MESSAGES GETTING DELIVERED?”
Koki
I can’t hold myself back. *sigh*
At Be after R5 we completely rewrote almost all of the user-space messaging code. Given that Zeta apparently comes from a snapshot that includes these extensive messaging changes, this article is incredibly superficial. At best.
And since I was somewhat disappointed that I never got to write a newsletter article about the new message code — if for no other reason than to use the title “BMessage: Faster, Longer, and Uncut” — here is some real information. (And okay, I admit it, I also can’t resist writing this because I am increasingly annoyed at how much stuff is mentioned being in these “new” releases of BeOS, when the vast majority of it is actually work that was done at Be.)
First you need to know about all of the messaging problems that existed in R5, which the rewrite was intended to address.
An old BMessage stored its data in a linked list, one entry in the list for each named field in the message. This had a lot of performance problems: finding a field involved a linear search through the message; copying a message required copying the entire linked listed; sending a message through a port required flattening that linked list into a (small and thus inefficient to manipulate) flattened representation, and on the other side parsing that representation from which a new data list is generated.
Sending a message to a handler — no matter how you did it — required flattening the message, writing that flattened representation into a port, and in the other thread reading and reconstructing the message. This happened for both local and cross-process message delivery. Besides the obvious performance issues, this had an even more significant problem: the looper’s port size was set to 100 messages, so in many situations it was very easy to swamp the port and as a result start dropping messages.
In order to address the performance problems, we completely rewrote the BMessage code. In the EXP code base, it stores its data in its flattened form; as a result, the object is able to read and write itself from a port without any intermediate flattening or copies at all. (If you look at the EXP BMessage, you will see the new functions WritePort() and ReadPort().) Even when flattening the message to a buffer or file it is significantly more efficient, since it essentially boils down to a memcpy().
Of course this means that BMessage’s flattened format has changed — which is a very important thing to be aware of when using EXP, because it means that any applications that store flattened messages on disk or send them across a network will be generating data that previous versions of the OS can’t unflatten. The new flattened format is quite a bit larger than the old one, because it is designed to be efficiently accessed directly in memory — so there is no data packing, and in fact padding is used in various places to make data line up on nice 8-byte boundaries.
There are some new BMessage APIs that allow you to request flattening in the old format (and the new BMessage can of course unflatten the old format), but the default is to write in the new format. In fact if we had ever gotten closer to releasing this OS, I probably would have gone through the BeOS code to explicitly request the new format where appropriate, and changed the default back to the old format.
Another performance improvement is that the new BMessage sorts its data by name, so looking up a field can use a binary search. (An O(log(n)) operation — much better than O(n) of the old message code.) In addition the message data uses copy-on-write semantics, so copying a message only involves twiddling a reference count, with nothing actually copied until one of the two messages is modified. The Zeta article is misleading in this in that BMessage doesn’t use general “reference counting” per-se, but specifically implements copy-on-write. (And the copy itself is of course just a simple malloc() and memcpy().)
(continued…)
Finally there is the issue of posting messages to loopers. In EXP the code path for local message delivery was completely rewritten — new facilities were added to be able to directly enqueue a message in a BLooper’s message queue from any thread. So now when you SendMessage() to a local handler, all that happens is a copy of your message is added directly to the looper’s BMessageQueue, from that looper thread will pick it up. And because of our copy-on-write semantics, this almost always means no copying at all of the data. In fact, when delivering a lot of messages (which is when performance really matters), the message delivery will usually not require any kernel calls at all.
Because we no longer go through the port for local messages, there are no longer any problems being able to deliver local messages. In fact the only way local message delivery can fail (beyond normal problems such as the handler no longer existing) is if the system is unable to allocate the 60 bytes or so it needs for a new BMessage object.
Of course this doesn’t address message delivery problems when going across processes, in which case we still must send the message data through the port. I did have some plans to address this, but never got around to it. It’s something you still need to be careful about.
One really useful new feature in EXP are some new APIs on BMessenger to deliver timed events. This allows you to post a message to a handler, where that message will actually show up at some time you pick in the future. This is incredibly useful when you need to do some easy timing for things like simple animations, flashing a cursor, detecting a button hold, etc. There are new BView APIs, DelayedInvalidate() and InvalidateAtTime(), that are simple implementations on top of timed messages.
I don’t really understand all the stuff about removing PostMessage(). In fact almost all that function does is create a temporary BMessenger (with the constructor that takes a handler and looper) and calls SendMessage() on it. PostMessage() has some yucky code that can end up reading stale memory if the target handler has been destroyed… but so does this BMessenger constructor. And in practice it won’t actually cause a problem. I would also strongly suggest keeping around BMessenger objects instead of raw pointers to handlers — it is quite expensive to construct a BMessenger from a handler. (With all of the messaging optimizations in EXP, constructing the BMessenger is probably more expensive now than actually sending the message.)
And how about this: “Another nice thing about BMessenger, is that you send BMessage refrences, rather than pointers.” Um, hello, I added those functions that take a reference while I was at Be. They work exactly like the ones that take pointers, but I put these in because once BMessage switched to copy-on-write it made a lot more sense to deal with it as a simple object (like BRect). This is great because it means the developer doesn’t need to deal with memory management… though of course it would be really hard to completely spread this new BMessage model through the API without breaking compatibility. (And don’t get me started on all the APIs that still take a “BMessage*” when the should at least take a “const BMessage*”.) At any rate, in all the message sending APIs whether you pass a pointer or a reference they work the same way.
And one final thing… “majik mumbo jumbo”? Give me a break. Hey if you guys have the source, take a look at src/inc/app_p/token.h. It’ll take you about a paragraph to actually describe how the handler token works — I am sure people would be interested, and it is in fact really simple. I even rewrote that thing while I was at Be to clean it up, so now the code should be nice and easy to understand.
So let’s see… from what I gather from this article, YellowTab has modified the Looper.h header so PostMessage() isn’t visible unless you set a #define. A change of questionable value, anyway. Yay, YellowTab!
— Dianne, who is sure she will regret this in the morning.
Very nice read Dianne. It does put the work at Yellowtab into perspective
FWIW, I also found the article at ytab *very* shallow – basically unprofessional, should have been a blog entry at best.
Lovely to see some of the real Be engineers speaking up =)
The big question though, now that yT’s work once again is questionable, is what she thinks about OBOS and it’s progress?
THX Dianne for more (much more) info
Et passe le bonjour à Mathias.
This is the second time I read people questioning Yellowtab source avaailability. The other person was the hacker of Phosphur.
Btw this be newsletter could have entered osnews’s article contest.
Ludo
—
http://www.mozilla-europe.org/
Are you married Dianne?
I always asked myself why Be developpers never implemented BMessage as a a flat indexed byte array.. On BlueEyedOS, I made flat BMessage from the beginning, not a bad choice seeing the work that Dianne started to clean the messaging system!
It’s even possible to make the flat BMessage structure match the port read & write API to avoid a copy overhead, majik mumbo jumbo ?
Regards,
Guillaume
Do you have at Be Inc at that time (some) documentation for new API at all? Maybe not so exhaustive as classical BeBook, but at least something more than comments in inculde files?
Or there was such lack of time and workforce so nobody took care about it?
Just wanted to let some of the readers here know that Dianne was interviewed by The BeOSJournal last November, 2003…
http://news.beosjournal.org/?id=617
Thanks Dianne for your wonderful two-part comment in this forum. It’s encouraging to see that you (and I’m sure other ex-Be Engineers) are still following the developments in the BeOS Community.
I personally subscribe to the no-source theory in regards to YellowTab, but that is just me.
Their “developer article” seems really lacking, imho.
I turned Dianne’s comments into article in Developer’s Corner at http://www.qube.ru – http://qube.ru/news/item/dianne_hackborn_about_bmessage_in_beos_5_1…
With all credits, so i hope Dianne has nothing against it:)
No good deed goes unpunished. No one here likes to be mislead, and we’re practically all a bunch of ‘Johnny Five’s… so, um, pardon us when we poke at you and shout ‘INNNNPUT’.
I commend your bravery – as an ex-be engineer you must have been aware of the attention this might draw, before you went to bed anyway:)
But in truth this is just a glorified thank you for giving us a little honest truth. These days ‘honest truth’ seems to be a such a commodity, we starve for it. So truly, thank you Diane.
I hope you don’t regret this in the morning, I really do.
Anonymous wrote:
> Are you married Dianne?
[sigh] Alas, I think some women are unattainable by mere mortal men.
> [sigh] Alas, I think some women are unattainable by mere mortal men.
However, I think she might be more attainable if you’re a mortal woman…
Anonymous @ dialup.mindspring.com, I was being subtle and complimentary. Not sure why that merited a somewhat crude and anonymous reply.
it’s mearly what I gathered by checking out her homepage (the big Gay Pride flag was a bit of a tip-off…)
And the S&M flag?
…
there is no Be anymore so why you dont help the guys they try to understand your code (and dont even have your code.)
she’s a pro, why should she help the guys from yt with a no future product for nothing. This was only a critic posting.
So, any ex-Be engineers that do not work for yT are “pros” while any ex-Be Engineers that do happen to work for yT are not? In case you all missed it, the original yT article was written by Alan Westbrook, who happens to also be an ex-Be engineer.
-Bruno
I’ll just tell you a new BeDoper is out…
http://www.bedoper.com/bedoper
You don’t understood, Alan Westbrook is also a professional progammer but he is working for YT. Dianne Hackborn don’t believe in YT and Zeta and wrote a critc posting. Why should she help the guys.
Well, aside from Dianne’s comments be readily adopted by Zeta-critics, they do point to some shortcomings on yT’s side. Alan, being the professional, should comment on them.
That he doesn’t sways me to suspect Dianne called his bluff…
If yT again remains silent, this is bad press for them.
Hello!
I personally like the affort that Yellowtab makes, to keep our BeOS alive. But it also hurts, watching the way they are trying to achieve their goals.
I am sure Yellowtab has the source code of BeOS. But they cannot use it because of the licences they have, or shall I say the possibilites they do NOT have.
They are selling an unfinished product, started by Be and of course Dianne (such as all Be engineers) is also is sorry about the fact, that programming R6 has not been finished by Be itself.
Yours, JLG