Linked by Thom Holwerda on Sun 9th Sep 2007 18:08 UTC, submitted by koki
BeOS & Derivatives "The primary intention of my previous article was to make it very clear why and when locking is needed in multithreaded applications. In this article, I want to present my experiences in writing a new prototype for a replacement of the document model in WonderBrush and how it is manipulated and rendered asynchronously."
Thread beginning with comment 269945
To view parent comment, click here.
To read all comments associated with this story, please click here.
tuttle
Member since:
2006-03-01

I was a big fan of BeOS way back. I even wrote some programs for it: http://www.gamemakers.de/tools4b/ . But while BeOS itself was pretty solid for me, I often had stability problems with third party apps.

IMHO the only way to make multithreaded programming acceptable for mere mortals is to have higher level synchronization primitives. Message passing is obviously one way to achieve this. The BeOS people knew that, so they made many of their APIs use message passing.

But writing a message handler in C++ is just a pain. First of all, you need to have strict rules for the ownership of the objects contained in the message. Otherwise you have a memory leak or a double free bug. Then you need to manually decompose the messages. The list goes on and on.

Reply Parent Score: 2

TQH ! Member since:
2006-03-16

So just because you had problems with third party apps crashing it's bound to be because of multithreading?

Ownership and garbage-handling, even with a garbage collector, is something you should always know and handle. For instance if you keep just one ref to an object it will most likely never be garbage-collected.

Reply Parent Score: 1