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 Fri 31st Aug 2001 18:31 UTC

[well, I'll have to re-type this message, my laptop died on me... because of a deadlock in the app_server. gotta love complex multithreading code.] I'm not arguing against multithreading, I'm arguing against the way it is forced onto BeOS developers, by making BWindows spawn threads, by having a messaging system that's too unreliable, by not providing services to make developers' lives easier. Multithreading is a good tool for certain problems. It is used under BeOS to solve problems that it isn't well-suited for, and sometimes to solve nothing at all. cedricd : -Well, you're the living proof that devs are lazy, and that an OS designer should make sure that the OS is as easy as possible to write code for. Not checking whether a memory allocation failed and letting the application crash will cause your users to lose data. In many cases, application crash with data loss is considered "no-ship" priority. The support costs associated with even one such crash will far outweigh the cost of writing proper error-checking in dozens of places as you write the code. -write_port, under BeOS, is far more likely to fail than new, and it is quite easier for an app to make all write_ports to fail system-wide than to make new fail in a single other app (other than, allocating all the system's RAM, which BeOS doesn't handle graciously either). -BeOS applications, just like Windows applications, won't behave well if you start spending too much time processing a message. It's a fact of life. Costly processing should be deferred to other threads. Network activity should be made asynchronous. That is true under BeOS, under Windows, under Linux, under MacOS. And it's unrelated to the number of threads you have to run each window : when a windows freezes after the user clicks a button, the user is unhappy about it. -Your mere request that documentation should explain how to write multithreaded code shows that it is not an obvious task. There should be an obvious way to write correct code, and optional ways to make it better or faster. BeOS doesn't offer obvious ways to write a correct multi-window app. -Some games other than Q3 are multithreaded, even on Windows. I know, I ported one of those from Windows to BeOS. Guess what : most of the bugs that were left in the shipping Windows version were threading/locking bugs. Sander : -Yes, the fact that BeOS can fail to deliver messages is an implementation bug in the OS, not an inherent problem of multithreading. That was the whole point of the question that was asked in the interview, and of the followup questions. -If your API is such that developers that are capable of writing correct code under other OSes are incapable of writing correct code for your OS, maybe something is wrong with you, not with your developers. -As I said, I can have the same argument about BeOS that you have under Windows : "Look at BeOS there are applications that can't close their windows while you hold the mouse button down." -I know a very good MT paradigm, provided by BeOS itself (heh, it also has a few good things). BLockers. --jbq