Linked by Thom Holwerda on Tue 26th Sep 2006 23:14 UTC
Thread beginning with comment 166336
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2006-06-09
I seem to understand that its own GUI/window manager was heavily threaded, and that its API encouraged multithreaded development in frontends.
But regarding the CPU intensive parts of a program not written in any OS-specific special manner (let's say the Gecko renderer, or the filters in GIMP) is there anything that BeOS does that is more SMP-friendly than other OSes?
Not only BeOS's window manager was heavily threaded, but pretty much everything in BeOS is, from top to bottom. In 1990's, it was not that common. For example, all drivers and kernel modules, file systems included, must be SMP-aware (no giant lock) and many of them even use extra threads to achieve better/smoother asynchronous I/O handling.
Kernel is fully thread-safe and use also threads itself. The BONE network stack use threading everywhere.
And, indeed, all userland servers and their corresponding libraries (BeOS "kits", aka C++ API) are threaded. BeOS kits not only encouraged multithreaded development but in the case of GUI, its enforced on the developer.
Which, in 1990's, unfortunatly, didn't help this IMHO great operating system to get quickly the critical mass of graphical software ported from unix or windows code base. At this time, before SMP became mainstream, multithreaded development and parallel software programming was not that well mastered by developers. Since, things have improved. Alas, Be Inc. was too early too small to survive during these years.
Beside this pervasive threading model, BeOS have no other "exotic" SMP features.