Hacker News new | past | comments | ask | show | jobs | submit login

"Where BeOS drove ahead of other operating systems of its time (and where Haiku is still ahead of contemporary operating systems) is that each individual application uses many threads. The core of the application itself has one thread, and each window the application creates has a thread."

I might not have been around when BeOS was first created, but this is certainly not a new concept today. I don't think I can name a major OS today that doesn't support this model. Both Android and iOS are well known for this technique, but they were hardly the first to adopt it.




BeOS was (and arguably still is) the only platform with a UI toolkit and system API that strongly encourages pervasive multithreading. Everywhere else, you have the option of writing asyncronous code, but the libraries are all designed primarily for single-threaded use cases.


Multithreaded UI toolkits have been tried and abandoned as impossible to program stable applications in many times, first at Xerox PARC (like so many other things people keep reinventing).


That also made it rather hellish to program, given you had 1990s multithreading technology and debugging techniques to work with. Something more akin to WinRT in Windows 8, where everything works through callbacks on a single thread by default, is a much better way to approach the problem, IMHO.


So, BeOS is somewhat akin Node.js for operating systems?


No, every other GUI is akin to Node.js (single-threaded event-driven), while BeOS is more like Java servlets.


BeOS's (intended) competition was MacOS 8 and Windows 95, which probably weren't that thread-savvy. In retrospect, the forced multithreading certainly improved responsiveness but also made porting software painful (since all other GUIs have a single event-loop thread).


This was not true.

On those days Windows NT was already available with a multithreaded kernel from day one and the ability to make use of them at the UI level as well.

When compared with the 9x family, yes, but not with the NT family.


iOS doesn't actually spawn a new thread for every window in an application. All of the UIKit calls are still very thread-unsafe and expect to be used only from the main thread. This doesn't really cause much of a problem, since apps are page-based: you don't need to update more than one or two windows at one time, anyway.


Yeah, for anyone who doesn't believe this, do a search for _WebThreadLockFromAnyThread sometime. All those Stack Overflow questions are from people who thought it was safe to have threads anywhere near UIKit.


Hmm, good question, concurrency and UIs seem a natural fit, what was some prior art and who used it first?

I can name Modula-3's Trestle and Pike's Newsqueak language/GUI from the top of my head. Didn't Xerox' Mesa use threads for this?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: