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.
E-mail Print r 0   · Read More · 53 Comment(s)
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 22:03 UTC

Well, losing a mouseup event is a fairly big deal in my book, and not something that might happen. What if, instead of losing a mouseup event (which is already annoying), you lose a message that you had to reply to within a certain timeframe (e.g. a BDirectWindow or BWindowScreen connection message)? When that happens, the app_server will instruct the kernel to kill your app. That's bad. And that's only one simple example. As for Windows stuff, the little I have learnt from Windows when porting a Windows app to BeOS is that it seemed entirely possible to have an application open several windows and not have to use as many threads. Furthermore, the idea about multithreading for networkign is pretty invalid in my opinion. A well-written application will use asynchnonous I/O to deal with that kind of situation. Async I/O allow to keep a good level of responsiveness without having to deal with dozens (hundreds, thousands) of threads. The problem with BeOS isn't the fact that the kernel allows for multiple threads. The problem is the fact that developers are forced to use multithreading under BeOS, that they are forced to use the BeOS locking mechanism, and that various bugs and limitations in BeOS make all that even harder than it should already be. Sure, a computationally intensive application might (and probably will) benefit from spawning an extra thread. Sure, a game that needs to send feedback to different output devices might benefit from putting the game engine in a separate thread. But in many cases, it's just overkill. --jbq