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 Mon 27th Aug 2001 23:03 UTC

Well, one classic example of things that can go wrong would be to open a terminal under BeOS R3, and to run something that'd print lots of text, like "yes". At some point, one update message can get lost, causing the windows to never ever update again. You only need to lose that message once, and the game is entirely over for your window. When working on native apps, the worst case I ever saw was bdb. Some parts of bdb work such that a window sends itself messages, while the debugger stub sends more messages. Under heavy load, some of those messages get lost, coming both from the stub and from bdb itself. The result was, bdb "forgot" some symbols, making it unusable. Just in case you wonder, there are many cases in BeOS where a window will send a message to itself, the most obvious being the default behavior of a BControl. When working on a port, the worst case I saw was a Mac application that assumed that it could do anything. "anything" included being able to call any method on any window at any time, including during an update. On BeOS, during an update, the window is locked, possibly twice or more if the update was triggered as a side-effect of a GetMouse. On BeOS, updates can really be dispatched to several windows at the same time. On BeOS, during an update, you are forcibly constrained to drawing inside your dirty region. Now, back to our Mac application which wanted to be able to synchronously draw in any window as a side effect of getting an update message in one of the windows. I let you imagine the mess. And, to precisely answer your exact point, I did indeed get into situations where I would lose a message related to a BWindowScreen::ScreenConnected(), such that the app_server would kill my app. Indeed, if you're consistently too slow processing messages because you are just too slow, you're not going anywhere. If you're just too slow because the kernel is busy paging your code bak from disk, and you lose messages because of that, there's a real problem with the OS. Guess what happens under BeOS. --jbq