Forcing a developer to use multithreading, which is pretty complex for most programmers to code for, it is the wrong way to go for an OS. There was some controversy about this, but at the end, the experienced programmers agreed. And Maarten Hekkelman, of the Pepper fame (Maarten is also the same person who wrote the BeOS debugger when he was hired by Be to do so), seems to agree too: There won’t be a Pepper for BeOS, just because the BeOS design does not make it easy to code such a big and complex app. Before you start replying in this story, make sure you read all the comments here. Our Take: I love BeOS, but BeOS is not perfect. In fact, what Be’s marketing was trying to sell as the best feature of BeOS, pervasive multithreading, it is also its most weak spot. Now you know why big apps crashing too much under BeOS, and why there are not many big apps available anyway. Too hard to code big apps for such an environment, for most developers. Take Scooby for example. This person’s multithreading code, is far below par, and mind you, Mr Takamatsu is an experienced developer. Scooby still crashes too much though and locks up the app_server at times, in a spaghetti multithreading confusion… Same goes for Gim-ICQ and lots of other apps.Update: Maarten Hekkelman responded to our comment section explaining his decision and Pepper’s design.
Making the Case for BeOS’s Pervasive Multithreading
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I fully back-up Maarten on his decision. Four months ago he was ready to go ahead with the Pepper port and I was his main beta tester. I reported some bugs and some weird lock ups (yes, I have a beta of Pepper for BeOS, but don’t ask for it
, and Maarten was afraid of these problems that they will surface. I won’t go into technical details, but talking to my husband (who is an experieneced ex-Be engineer) did not help him greatly, as the problem is with the OS, not with the actual code or Pepper’s design. The idea was to create a giant lock around Pepper, so it will behave like a single-threaded app inside a multithreaded environment. Too much work to do so, and at the end of the day, it is a gross thing to do. So, no Pepper for BeOS…
It is a great app btw…
BTW, does anyone remember the port of Steinberg’s Nuedo for BeOS that was never released? That is a huge, professional app. And GeB, had to create a giant single threaded lock around the app in order to port it.
http://www.amigapro.com/Images/WBScreenShot.jpg“>AmigaOS” rel=”nofollow”>http://de.amiga.com”>other operating systems and devices) as well?
I’m not sure I understand how everything works, so I hope someone helps me here. Are the problems mostly when there are two windows controling the same thing? Is it a problem with communicating between two views in the same app? Couldn’t messaging fix this?
As I said, I’m new to C++ (Delphiholic for years) so I’m trying to pick up some C++ on BeOS on the side. Wouldn’t messages work in this situation?
>Couldn’t messaging fix this?
BeOS messaging is one of the big problems regarding the bad multithreading. If you had read the comments in that link I gave you (please do), you would have seen that BeOS *LOSES* BMessages very regularly. So, when the messages are not delivered, and most importantly, when you do not add special code to check if the message was delivered, you are toasted.
My bad – sorry.
Nuendo exists on Macintosh and probably it will be updated for new CoreAudio
APIs but, while reading the technical note on its threading architecture,
http://developer.apple.com/technotes/tn/tn2028.html, it doesn’t seem to make
easier programmers’ life. In Apple new OS threads seem to extend abnormally
in a orthogonal direction: Carbon threads over POSIX threads over Mach threads…
Eugenia a question for you,
What is your opinion regarding Amiga’s new operating systems (both AmigaOS 4.x PPC and AmigaDE). I think even for todays standards the http://www.amigapro.com/Images/OS3.9.jpg“>operating for classic Amigas is very flexible and powerful. I haven`t used AmigaOS for quite some time myself, but I loved the way AmigaOS worked.
Thanks!
Amiga was great back in the day, but I have not used any of the two versions you mentioned (4.x and DE), so I can’t really say.
I mostly use Windows in a laptop these days as the PC that has all my 7 OSes in it, is still locked in a public storage.
I do give some attention to AtheOS lately though. I have ported 7 apps for it, but I haven’t publish them, as they are also locked in that public storage room along with my PC.
I doubt there is anything inherently difficult to program about multithreading. If you think about it, Windows 2000 programs use multthreading almost as extensively as BeOS programs, even though they are not forced to. With the basic system and a few MS apps running, the thread count on a Windows machine tops 200, while it is around 150 on BeOS. Yet, Windows 2000 has many very large applications, and is quite stable. Also, the multi-threading helps give the Windows UI the unmatched responsiveness that it enjoys. There are probably factors that make multithreading on BeOS less than ideal (a system that loses messages would be one of them), but multithreading itself is probably not at fault.
I have to agree with Rayiner (BTW I am not an expert on this).
Multithreading is great although in my experience with programming the BeOS, I never came across problems, probably because my projects were not large enough.
Surely the multithreading is just broken, as other systems seem to be able to cope okay with it.
Just my 2 pence.
The problem is pervasive multithreading in the user interface, and that developers are forced to do this. Multithreading is great when the developer can choose when to use it (and makes this choice carefully). The problem with BeOS is that it forces developers to multithread even in cases where it doesn’t make sense. Most of the time, the UI can perform plenty quickly with a single thread.
When the OS forces multiple threads into your application design where they don’t belong, instability ensues. This was especially common when porting apps from other platforms – the developer had to take into account synchronization and locking issues that didn’t exist on other platforms, and had no option to skip some of those threads BeOS forces on you.
..elightening news story, I guess. Or maybe it’s aiming at the same goal that the latest news stories on benews were (noticed how there were less stories one the commenting forum was down 🙂 Hope someone catchese the inference..
Thanks for all of us developers of stable apps, who should then consider they were not “big” by any strecth of the mind since by A+B they wold necessarily have been unstable otherwise :-). Bah. There’s still ArsTechnica. (too bad it’s down currently, or is it just me ?).
It’s important to make a distinction between the idea that forcing a developer to use threads is bad (IMHO it isn’t) and the fact that the interface kit in BeOS is a broken design when it comes to BLooper locking and BMessaging.
What is your problem Cedric?
If you don’t like it over here, please do not visit us. You have promised me the same for Benews, but you were always there, trying to be the “opposite power” of everything we said.
I do not understand your opposittion today. We did not publish something that it is not true, in fact, it IS an enlightening story for lots of BeOS people. Developers or not. There was a definite news story about Maarten’s decision and email as published on BeForever. In fact, exactly because I am a developer myself, I find Maarten’s email and the things he talked about very important! And I want to share this knowledge with the beos readers over here too.
I am sorry for speaking my mind, but this is what I always do, you have to know me by now. I am a bit direct most of the times, but this is how I am. Diplomacy is not my friend.
As for ArsTechnica, it works fine here. Maybe they have locked your IP out. ;D
Anonymous No2 (IP: 12.39.137.—) , thank you for your post. Really good one.
What wonders me is that this seems to be a major architectural point in BeOS’s design and it hasn’t been raised earlier. Be’s engineers always seem to have had a clever, clean way of solving problems. Is there a possible solution (architectural changes) to this problem? At least a new release that breaks binary compatibility?
The problem is quite simply the way BLooper works wrt locking, and distributing BMessages. It’s quite simple, and unfortunately a bit fundamental to a lot of IK classes.
It is perfectly possible to write large, working BeOS apps using the IK, if you design with those problems in mind. The problem becomes larger when porting apps to BeOS.
Multithreading is a mixed bag – it bites you the first time you encounter it and it does require extra attention (locking, buffering etc, essentially slowing your development time down), but the capabilities it provides far outweighs all disadvantages. Multithreading every BWindow with its own BLooper is probably excesive, which is probably the gist of the gripes developers have. The OpenBeOS crew should consider having a BWindowChild class (with the same BLooper as the parent).
Hats off to Gobe. When tamed, the multiheaded master works for you.
Hmmmm, What exactly constitutes a “big app”?
Is Gobe Productive a “big app”?
Is Mozilla a Big “big app”?
I can’t imagine why the physical size of an app would effect pervasive multi-threading!
Are you saying that if I have two apps that have the exact identical level of complexity in terms of threading, and I add more extraneous code to one of them to make it fat, the fat app will simply die of cholesterol? Does it matter if the app is modular?
I can’t understand this whole thread crashing because of code size concept.
Eugenia, since you opened the can of worms, how about a more indept article on the issue.
Get help from Maarten and/or your husband if necessary.
ciao
yc
Eugenia,
What’s happening with BeNews? Has it been renamed OSNews?
What’s with this Hercules OS 1.0 from Palm for Arm processors? (http://www.arstechnica.com)
If you owned BeOS shares, how would you vote on this Palm deal? (For or against?)
Do you think Palm will release R6/Bone for Intel after the BeIA for StrongARM port?
ciao
yc
1. BeNews is down, I don’t know if it will ever come back again. It depends if our admin drive 1 hour away to restart the server…
2. I have no clue, I will research about it.
3. Thanks God I do not own any Be shares. But personally, I would probably vote for it, not because I agree, but because there is not much else to do, I guess… But don’t take financial advices from me, I got no clue about shares and stuff.
4. First of all, there is NO port of BeIA to StrongARM. Take my word for it. The Be engineers are working with the Palm engineers to enhance or rewrite parts of the existing PalmOS. BeIA cannot be ported to ARM for technical and other reasons. Personally, I do not believe that Palm will ever do anything for BeOS either..
You obviously didn’t read the links she posted, because they are very in-depth. It’s not the physical size of the application; it’s the complexity.
Users treat windows as separate thread contexts. They expect to be able to interact in them independently and asynchronously, and they HATE it when one window’s processing causes another to not respond. This is one of the main points of a WIMP interface paradigm.
The reason the BeOS UI is so responsive (Rayiner thinks Windows’ UI is more responsive?!?!?! Or perhaps I missed the sarcasm…) is that it forces the developer to take the way users deal with windows into account. Tho it makes the developer’s job more difficult, this is a GOOD THING. Larry Wall said it well: simplification is good, but oversimplification is VERY VERY BAD. In addition, BeOS uses operating-system constructs like pre-emptive threading to ensure that the stupidity of one developer can not interfere with the rest of the system. The result is a more-interactive system than any other.
That may make it harder for large apps (news flash: it’s hard to write large apps that feel good on any platform), but not much harder. As already mentioned, it’s not that hard to serialize whatever needs to be serialized…but it should be the conscious decision of the developer to take that risk of bad performance, NOT the default used in most apps. Pervasive multithreading encourages the developer to make their UI asynchronous as users expect but it does NOT force them to have a multi-threaded logic engine (in fact the standard way is to put that logic in your BApplication; a single thread).
Bugs in message passing aside, I think it’s a fallacy to say that BeOS is broken because it’s hard to port badly-writen badly-performing applications: BeOS requires apps to be more interactive than most operating systems, so things that aren’t will be hard to get working. I don’t know what kept Pepper from working correctly, but it IS possible to write large, complex applications using the Be UI, and in my experience they BENEFIT from the multithreading.
I wrote a complex multimedia kiosk application using Windows, Java, X, and BeOS. I designed them each from scratch, but with the same goal in mind–I did not try to force BeOS designs on X or vice versa. But in the end, the BeOS app was chosen (by people biased AGAINST BeOS) because its design was simpler and it ran smoothly on cheaper hardware. It wasn’t the largest app in the world but it was quite complex, and it was much easier to make pleasantly interactive under BeOS than any of the others.
If you want simple development, write (single-threaded) console apps that read from stdin and write to stdout, and nothing else. (BTW, you can do this just fine under BeOS!) These are fun, simple, and I write them all the time. But if you want interactivity, you’re going to have to take the plunge and think about a good design that lets the UI be asynchronous. The Be API forces you to do that, instead of counting on developers to do it without motivation. The result is better apps and a better user experience.
Why does BeOS lose messages? Is it a feature or a bug?
Users only *think* they interact asynchronously. You’ve got a big synchronization primitive on every user interface called a “mouse”. I’d like to see you try to interact asynchronously with an application.
If you’ve got a lot of processing to do in a certain window, then by all means, spawn a thread to do the number crunching. This applies to BeOS, Windows, etc. But not *every* window deserves a thread of its own. Think of a tool palette with buttons for paint brushes, selection tools, etc. – does this window really need to run independently of the rest of the app. No.
Another issue with the BeOS implementation was that you weren’t allowed to do a lot of processing in a window (even though it ran in its own thread and this might seem like a good idea) because you would clog up the message loop and lose messages. This meant for complex calculations you had to spawn another thread anyway. Now you’ve got two threads per window – where’s the sense in that? The annoying thing was the phrase “a lot of processing” – basically you had to keep the window’s event handling thread running as fast as possible, because the threat of lost messages was nipping at your heels. I for one do not appreciate it when my code runs correctly on a fast machine, but crashes on a slower one, or when other apps are taking processor cycles as well.
Perhaps the fact that I was a Be employee or that I learned to do multi-threaded programming on BeOS, but I never found it that difficult once I grasped the basic concepts involved in multi-threaded design. For any application based around BLoopers (and their derivatives) multi-threading is pretty much transparent. (Well, at least some what; you can send BMessages to those other threads just as you would to any other part of the OS or other applications.) The hard part comes in when using the lower level threading API; such as creating a thread with spawn_thread(). These functions aren’t extremely well documented (I constantly had to refer back to the R4 Be Book for examples), and require a bit of concentration and fore-thought. You have to be concerned with scope of variables and the data they contain, race conditions, and, naturally, logic. I don’t see how this could be any different than on any other platform that supports threads.
BLooper based objects drop messages typically when the queue gets filled faster than it can remove items from the queue. This means that anything that requires a lot of processing time should have it’s own thread. BWindows (which is a BLooper derived class) are meant to be responsive. So instead of placing your ray tracing code right there in your BWindow class, put it in its own thread. Use BLoopers for things that are quick and/or repetative: checking to see if a file exists; sending a ping out to a network client on a regular basis to confirm it’s still around; triggering a system event.
In my opinion, the pervasive multi-threadedness of BeOS did not contribute to the lack of big applications on BeOS. It just wasn’t as big a marketing ploy as Be had hoped it would be. Otherwise, all these other OS’s that support threads throughout the system would be experiencing the same difficulties getting the big apps done. I think the truth of the matter is that the Linux/Unix folks had their multi-threaded OS (and to some extent believed rightfully and/or blindly in open source as the way of the future) and weren’t willing to learn to do threading in a slightly different fashion on a new OS. If they had taken BeOS as many others did, and maybe if Be had pushed BeOS a little harder after the release of R5 Personal Edition, then I think we’d be looking at a very different picture of Be right now.
And if I had won the lottery ten years ago… 😉
Both of these discussions have been interesting, but they still leave me wondering if the whole idea of “pervasive multithreading” is fatally flawed, or if the problem was just with BeOS’ implementation. Let’s leave aside for the moment the issue of whether having a separate thread for each window is excessive, and let’s also assume that the developers for this hypothetical OS are experts at writing threaded code. Is there some reason that makes it impossible to design an OS that won’t lose messages like BeOS sometimes did?
btw, in the above post, when I said “developers” I meant “those writing applications for the OS”, not the developers of the OS itself.
It seems to me that the real problem is BeOS losing messages. This is a bug and should not occur. Perhaps a BeOS engineer (ex or current) could tell us if it is fixable or not.
I have very few problems writing multithreaded applications. I did a lot of my coding on the Amiga so a lot of the concepts were learnt early. I can see how it would be a problem for someone who is new to such things.
Cheers
David
Well – I’m just an old BeOS – User, less involved in Programming (sorry), therefore more involved realizing perfect dayly work on BeOS. And showing that to our customers.
Customer demands aside – working with that at home on a scsi – system (SMP PIII) is a joy. The lack of the browsers are annoying – hell it is so. Incompatibilities between Netscape / MacOS – Version are a mess, too…
So I work pretty with Gobe (isn’t a small app) – never locks.
E-Picture is a bit buggy – but once you know the tricks it’s a great tool & very professional to work with.
T-Racks never crashed one time, Eugenia – a small app ? No.
Personal Studio seems to be one big app which sometimes got synchronisation problems. That’s true in here. But like in any other OS it’s a user handling issue which destabilizes the app to (or the hardware environment)
A friend swears for Moho 2.x on BeOS (I don’t know that).
<P>
I think, it’s a programmer’s matter : if he makes shitty programs, he will do that on MacOS as well. Pro’s & Con’s are everywhere. Generalizing that big apps aren’t possible on BeOS is not what I will verify. That isn’t true.
<P>
The memory allocation issue seems a bit more problematic for me than your hint (you know the big RAM issue for BeOS – I had that problem, too (512 MB RAM) . Putting the disc cache size up to 16384k in the user kernel settings script will lower the problem.
But when you copy huge files from a 4096 byte – Cluster Partition to a 1024 byte Clustered Partition you wil face that problem again (for example copying a single 8GB – cut together HQ RAW Video from one partition to another (yes – a 12 GB – file IS possible, folks)…
Regards
… to Eugenia. Indeed in the last few days of BeNews before the (temporary hopefully ? *G*) downtime I was posting way too much hot air in the forums, nearly as much as I’d consistently doing here for each and every news item, vainly trying to educate people like if I was a supreme code-fu master or god or something, and like if osnews was posting FUD items, which is too far stretched if not completely false, even. Sorry about that. And also for mentionning an inference to catch, I guess it was too transparent and thus felt like an aggression or something, which would explain your being shocked by my message. Osnews is osnews is osnews. I will try not to annoy you any more. Thanks for your time (or more like, sorry wasting your time, will try not to any more), hope the best for ya all. Windows is looking good. Stability as much improved I hear, and for people less desperatly stubborn than me it’s the adequate ersatz with no problem I think 🙂 Aaah politics.
Designing multithreaded apps is hard but multithreading is NOT a design flaw. There is absolutly NOTHING wrong with Be’s threading model. In fact I rather liked it. If people are having trouble getting their apps to work on the BeOS because of threading issues it’s because they either don’t really uinderstand how to design a multithreaded app or they don’t feel like making the effort.
Let’s face facts. All those cool apps that were announced for the BeOS never appeared because for all intents and purposes the BeOS was useless for anything besides email and some lightweight web browsing. I still can’t believe that Be branded the BeOS as the Media OS. Why would a mucisian, artist, webdesigner, etc. invest in the BeOS, which had zero working solutions, when there were already hundreds of mature working solutions for Windows OR the MacOS?
I completely understand why companies bailed on the BeOS. They bailed for the same reason I did. They spent thousands of hours and tons of cash and made nothing in return. I wished I had invested the time and money I put into the BeOS into the MacOS or even Windows. At least I’d have something to show for my efforts. All I’ve got now is a bunch of equipment, software and code I’ll never use. To be honest I wish that I’d never heard of the BeOS. The resources that were spent on it. What a waste.
geoff
We’ve had this discussion some time ago (though I don’t know where it was) and it all boiled down, that if the “lost-of-the-bmessages” would be fixed then the “pervasive multithreading” is no problem. Or at least not such a big one…
I’ve only ever really done much programming of this sort on my old Amiga, and not for a few years now (I use VB on my PC so I don’t have to worry about Windows poor design, or lack thereof). I’d have to agree though, forcing threads where not actually needed is, at least, irritating. I’d only start a new task to offload something that was going to take more than a few seconds to complete. User’s interact with UIs in a serial manner (as someone else pointed out, you only have one mouse), and probably expect the odd pause after the issue a command. These are application design issues, not OS issues (and I also agree, most apps are badly designed…)
And any OS whose IPC is not reliable strikes me as rather broken.
Thanks for the reply post on BeNews/BeOS stuff. It’s greatly appreciated.
ciao
yc
BeOS makes threading easy. While every window may not need to be a separate thread, it really does not hurt if the kernel can handle it. How many windows are you gonna open in all your workspaces 100 perhaps? Not a problem.
Now if the BeOS pervasive threading mechanism has a bug that’s another story but the concept is technically sound!
BLoopers and BMessages make up the best threading/message handling mechanism on any OS today! (IMHO)
Long Live BeOS.
ciao
yc
Indeed, the concept is technically sound, but just because you can do it doesn’t mean you should… I’ve nothing against multi-threading, and if BeOS makes it easy, then that is great, but don’t use a hammer when you really need a screwdriver. Anyway, you can increase the responsiveness ‘feeling’ of a GUI by having the GUI run in its own task and get it to do basic rendering so the user gets feedback on their actions immediately, even if the result itself is delayed for a while. Of course, if it will be a long while, then maybe more threads would help.
Stories like this depress me. I love BeOS more than pizza and I pray for it’s continuation, but can this be fixed? What would it take to do so? Is this like altering a pyramid’s corner stone?
I don’t see how anyone would want to develop applications unless this were fixed, as well as whatever bugs took personalStudio away from us…
I still can’t believe that Be branded the BeOS as the Media OS. Why would a mucisian, artist, webdesigner, etc. invest in the BeOS, which had zero working solutions, when there were already hundreds of mature working solutions for Windows OR the MacOS?<p>Speaking as one who was (& still is) interested in BeOS for exactly this reason, let me point out a couple of things: First, many artists can’t afford Mac hardware (not to mention that, IMHO, the UI was pretty clunky) – musicians have to buy other stuff like instruments, mics, recording devices, as well as invest in various promotional aspects. If they can get a good working system for less than 50% of the cost of a Mac, they will be interested – I was. If it wasn’t for this fact, very few people would be using Windows for multimedia – they certainly don’t use it for its performance. Certainly, I wish the full-featured apps were there – and I suspect that the companies that WERE producing them before the BeIA debacle believed that there was a potential market, or else they wouldn’t have bothered at all. But, even with the freely-available stuff it’s quite possible to create good recordings with a modest PC, while my experience with certain well-known commercial packages on Windows was far – FAR – less successful.</p><p>Basically, I believe a system optimised for this kind of work was/is a sound idea – and I think Be should have stuck with it, rather than chasing the gizmo-of-the-week market. (my 0.02)
Pepper uses a single private disk cache to be able to work with files unlimited in size (well, up to 2gb actually) with support for non overhead unlimited undo while still using a decent amount of memory (typically 4 Mb). Pepper allows several sources of input, user typing text and command line apps piping. It is also possible to have multiple windows displaying the same document. Now try to wrap this up in a way that is safe and protects you from data corruption. I can tell you, that’s an awful lot of work and I think not worth the trouble. I rather spend those hours implementing even more cool new features.
I know about single writer multiple reader locks and such. But hey, I wanted to write a nice text editor with quite a number of cool features, not the next big RDBMS. I’m not against multiple threads, but I’ve learned that there are other ways to make responsive user interfaces. Much safer ways.
Maarten,
I surely don’t think you’re a weenie or something like that. I love Pe and I know you have to be good to code something as great as that.
But don’t you have the same problem on the other platforms ? If you allow multiple input methods, they have to wait for access as well, or not ?
And not to sound like some smart guy, but making a buffer that only one thread at a time can access is not that hard. Using RDBMS techniques is way over the top in this case.
Back in the days when a simple eventloop was the way to write software, there was the concept of tasks. Create a list of objects that get called onces per cycle. Poor man threads, but much easier to implement and safe. In one such task you can use select to see if anything is ready to be read in. Nice and easy, proven technology and access is strictly serialized.
Of course you can make a buffer thread safe, but what if you want to share a cache among several buffers?
I’m not responsing to any particular post on this thread but:
1. Asynchronous UI is good. I do like BeOS’s implementation on this. It does have it’s problems and limitations, but interactivity under BeOS was a very fullfilling experience.
2. Pervasive and easy to use multithreading is great. I do a lot of “service” development under NT (Win2K) and developed several small apps under BeOS. I LIVE in a threaded universe. I will say it took me some time to adjust to this method of programming but once I “got” it development came naturally. There is some additional complication with multithreading, but once learned the ability to efficiently performe more than one task in the same “logical” time is great. Higher levels of responsiveness for the user, better use of CPU for the computer.
3. Need better language support to really get the true benefits of multithreading. C/C++ is portable assembly and *can* be used for writing multi-threaded programs, however, it is not the best choice, why?
– Memory management – if a thread dies C/C++ runtimes don’t know how to properly clean up. Sure C++ exceptions can provide the programmer the opportunity to clean up, but there are no guaranttees that the clean up will be correct or complete. Also, if a thread dies for some other reason other than an exception, then the C++ runtime is never even involved.
– Memory protection – C/C++ simply doesn’t protect memory, different threads can trash memory
Now, before readers say “For language: Java, stupid” or “multithreading should be up to the programmer so BOTH multithreading and synchronous programming should be supported” I say:
– Java’s threading support is dumbed-down, like most of the language. Now don’t flame me yet. This “dumbing-down” was done for pratical reasons, and I acknowledge those reasons as being valid, but there are times I want more, Liek real semaphores, events, etc. And yes, I know you can build them given one mutex primative, but Java is NOT a multithread RICH language; instead it has a straight-forward to provide a minimum to make the claim.
– Providing a system/run-time the supports BOTH multithreaded and synchronous programming results in Microsft COM-like threading “models” with all sorts of restrictions and rules that just suck! Like the UI having to be in the primary thread of the application and COM-controls forceably being single threaded. So, NO I would say that it is BETTER to have an environment that is multithreaded by nature and provide single threaded wrappter libraries for those who can’t pack the gear.
Jim Powers
I can understand where porting a serialized type application might be diffilcult to port, especially one that had many windows, but developing applications with threads is not diffilcult at all. I have developed many large and small applications that have threads when needed, and its not that hard. I have never experienced “lost” messages. As long has you lock and unlock when trying to change the state of the contents of a thread (eg window), then it is not a problem. Threading under BeOS is not more diffilcult than threading under another OS. Unless you were told and knew already, the window, being in its own thread for you does not make it more diffilcult. If you statically passing state around instead of using the message handlers, you may get into problems of lock up.
I pretty much agree with rancor. Both sides of this argument are right, and wrong: a multi-threaded
API is a good idea, and it’s too hard. (Maybe this perplexing conundrum is what keeps Mme. L-Q
so interested in this subject.) It’s too hard because we have to teach ourselves how to do it with
lame tools like C++.
I see in another article here that one of the Amiga efforts is going to come with its own functional
language, and that’s interesting because it’s just what I think I would want to do for this problem if
I had a new OS to launch – provide a development language alternative to C++, with a natural
facility for an asynchronous programming model. That’s not a wild dream – Erlang, for example,
has a reputation for reliable, massively multithreaded software.
I would hate to design an operating system to accommodate poor programming tools and thick
headed programmers who can’t learn anything new, if it’s really not necessary. I think the tools
are there, and people are eager to learn new things that really work.
I tend to disagree with people about the mulit-threading issue. I think that it’s awesome. I am currently trying to port BeShare to windows (ever heard of WinShare?
), and am finding that the lack of BeOS’s multi-threading in Windows annoying. I have to create my own thread for the networking part so I don’t lock up the GUI 
. In BeOS I could just derive froma BLooper and away I go. And I could even send it messages! (Such as went to grab the status from the server, etc.) Instead, I am forced to keep an ongoing loop going… Using select() to wait for more data (ick!). So when I want to quit the thread, I have to kill it!
z\\
z\\
You could just as well say the BeOS has a bad design because it forces developers to use OO techniques whereas the majority of programmers still think procedurally. Yes, it takes time to wrap your mind around MT, but actually it is a nice extension of the OO paradigm. It forces you to really think about who owns what data, and who is allowed to change what when. You can’t get away with a big hunk of global data anymore.
That being said, maybe there’s something to be said for a “clunky” mode in which everything runs in a single thread for compatibility with old, non-responsive, single-threaded apps.
Numerous posters mentioned/complained that Be’s “pervasive threading” would be much easier to cope with if messages weren’t lost all the time. It seems to me like the reason why messages are lost are apparent after Raymond C. Rodgers’ post.
If a thread is ignoring incoming messages for an extended period of time because the thread is busy, what should an (any) OS do. Certainly, the OS just somehow find more buffer space to hold the overflowing messages for the thread so that messages are not lost. But what if the thread never examines another message because it is locked in a loop somewhere? The OS would have no way of telling a locked up thread from a busy thread. It would seem silly to start dedicating every increasing amounts of memory to a thread that is not responding to messages. I suppose the logical thing to do then, is to either drop the messasge or kill the non-responding thread.
If the above reasoning is not flawed somehow, it would seem that Be’s implementation is perfectly reasonable.