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 Wed 29th Aug 2001 19:50 UTC

Well, Kurt brought in some extra details. BeOS can block on a port write when the port itself is full (each port can only hold a fixed number of messages). The real problem is that the BeOS kernel allocates the data associated with each port message from a separate (small) memory pool, and write_port will fail if that pool is full, returning B_NO_MEMORY. Annoyingly, this "feature" doesn't seem to be documented in the Be Book. Filling up the memory pool with have some very negative effects on the system, usually causing the app_server to deadlock. Even if write_port could be guaranteed to block forever and never return any error code, the problem wouldn't really be solved. Applications wouldn't lose messages any longer, but would deadlock instead. Kurt is right indeed when saying that the problem has nothing to do with multithreading. It would (and does) also occur when communicating between single-threaded applications. The fact that BeOS forces multithreading onto developers makes that bug much more annoying, because developers will have to go through that codepath even for messages that stay inside the application, and because a developer usually won't expect a message sent inside his applications to get lost, especially when no documentation warns about write_port() (and thus SendMessage() and PostMessage()) possibly returning B_NO_MEMORY. So, let's try to summarize : -One of the highest priorities for a message-based OS should be to make sure that no messages should get lost, and steps should be taken to avoid that case. Specifically, the kernel should only lose messages under cases of "catastrophic failure", and one of the available options in that case is to kill a random application. BeOS doesn't consider that issue as a priority. -BeOS forces multithreading on developers, putting them in situations where they have to extensively use messaging, implicitly or explicitly. -Combining those two problems makes BeOS an unnecessarily tricky platform to develop for. --jbq