OSNews

and the apps did not need to be multithreaded in the same way as in conventional os:es as the kernel handeled it.

Incorrect I'm afraid. BeOS forced developpers to write multi-threaded applications, unlike the other major operating systems.

Which meant BeOS was more responsive in general, and more adapted to multi-core by default, but also that development was harder and that there were less applications available.

And it wasn't a microkernel.

BeOS apps had to be multithreaded in the same way as apps on any other *NIX-like kernel. The OS didn't handle anything. All BeOS did was to put each window in a seperate thread. That wasn't a throughput issue at all, but rather a latency one. The GUI processing isn't intensive enough to need more than a single CPU; multithreading the GUI just fixes the problem of servicing GUI requests promptly. BeOS's responsiveness could've been achieved (more easily in fact), by simply building the GUI toolkit on select() instead. Both would fix the responsiveness under load issue, and neither would make your app run any faster.

As for BeOS's scalability, it wasn't there. BeOS's interactive scheduling was very good, but the scheduler choked after only a few hundred threads. Even NT4 at the time could handle large number of threads more gracefully, though its interactive heuristics weren't nearly as good.

Using synchronous event handlers within a multi-window single-threaded message loop would not provide equivalent responsiveness to the same in a multi-threaded set of message loops on a multiprocessor system. The BLooper class implements an event handler in a manner not dissimilar to one implemented in terms of select, so this whole "more easily" stuff is nonsense. The architecture of an event loop does not vary significantly across platforms. When people complain because their Gtk+ program stops redrawing the UI because an event handler is blocking, they're experiencing what a simplistic single-threaded select-based event model degrades to. Whether throughput would be affected is largely dependent upon the nature of the event handlers called by each BWindow. That is to say "it depends." Further an event loop does not do anything to alter responsiveness under load--that's a scheduling matter.

The BeOS's threads were expensive especially in construction, and the one window = one thread idea was probably a lot more useful for marketing than development: creating a crapton of kernel threads is hardly a scalability win.

First off the original poster (judgen) had little knowledge of BeOS. It was not a microkernel, furthermore the OS itself could not "magically" thread apps that had not been mutltithreaded by the programmer.

Those deltas in perfomance by adding multiple processors were wishful thinking. No matter how many processors you have in the system, if the application has not been threaded or simply has very little instruction parallelism.. you will not see that much of a perfomance increase no matter how many processors and fancy OSs you throw at it.