Linked by Eugenia Loli on Mon 27th Aug 2001 05:22 UTC
Syllable, AtheOS AtheOS is a modern, free (GPLed) Operating System written from scratch in C++. A big chunk of the OS is POSIX compliant, supports multiprocessing and it is GUI-oriented (fully OOP). Today we are hosting an interesting interview with the AtheOS creator, Kurt Skauen. Kurt is talking about his views on binary compatibility in future versions, multithreading and the future of his OS in general.
Permalink for comment
To read all comments associated with this story, please click here.
Re : multithreading
by Jean-Baptiste Queru on Thu 30th Aug 2001 17:55 UTC

cedricd wrote : "I don't even take taht into account when writing code or it would be unnecessarily complicated/bloated". See, we agree. That's where part of the real problem really lies. That "unnecessary" code becomes necessary if you want to charge hundreds (or even thousands) of dollars for your code. cedricd also wrote : "it never happened to my apps AFAIK". Well, maybe you didn't test your apps enough. It's fairly easy to put BeOS in a situation where problems happen. Getting write_port to return B_NO_MEMORY only needs 5 lines of code in another app (but running that kind of stress usually kills the app_server). Getting write_port (PostMessage/SendMessage) to block or timeout is a bit more interesting to achieve (the easiest way is to script-flood one of your loopers from another application). If you're really serious about testing your code, this is something that you should try to do. Sander Stoks wrote : "Multithreading is good". Sure it is. Asynchronous code is good. Having multithreading as an option to write asynchronous code is good. Making it the only option is not. Hordes of new BeOS programmers have had to use multithreading without understanding it, giving us the Baxters and Scoobys of this world. Those beginner programmers should have the option to code pure single-threaded synchronous code, and then, when they become more confident in their skills, switch to a more asynchronous style of programming with either multithreading or asynchronous I/O (or even signals). If a Windows application stops dispatching messages, it'll become unresponsive. Guess what? the same thing applies under BeOS. And I equally dislike a BeOS application that freezes on me as I dislike a Windows application that freezes on me. As a developer, I really don't feel like living with the fear of losing messages. What about the message that says that the document must be saved? Your user won't be happy. What if your photoshop loses the message that transfers ownership of a 100MB undo buffer? You leak 100MB of RAM. What if you lose a B_QUIT_REQUESTED message? the shutdown process gets stuck. What if, simply, your user clicks a button and nothing happens? Your user gets unhappy about your app, thinks that it's unreliable. martijn sipkema wrote : "bcontrols [...] send a message when invoked without containing the new value". I thought they did. Check for a field called (if memory serves right) "be:value" in the message you get from your BControl. Or, in doubt, to a BMessage::PrintToStream() on that message and run your app from a terminal. OK, to be clear : I'm not blindly against multithreading, I am all in favor of tools to write asynchronous code, and multithreading is one of several tools available for that ; multithreading is needed on SMP systems, but multithreading also can't take care of everything (try to run an IRC server with one thread per user). However, I am convinced that one thread per window is overkill, especially when messages can't be guaranteed to go through. I wouldn't wnat to have to sign off on apiece of code in such an environment. --jbq