QT 5 launched by new owner, Digia

* APIs blocking on network operations (e.g., gethostbyname())

How does BeOS avoid/avoid lagging with these things?

Windows and Unix app developers have been used to doing everything on the main app thread, and everything is geared around that.

The Amiga couldn't afford to do that, as the machine was so slow that the UI would be unbearable. Modern OS's get away with an architecture that makes it ok to be lazy, because the machines are fast enough that it's just an annoyance.

Consider for example, that to make cut and paste fast on AmigaOS, one "Task" (thread/process) would send a message stating what parts of it's UI data it wanted copied to the clipboard. Another task would then copy the data, and confirm and write the data to the clipboard. Why? Because the clipboard could be on a very slow device (in theory on a floppy, though usually no slower than a slow harddisk).

AmigaOS was infused with design decisions like that: UI "gadgets" (widgets, buttons, whatever you want to call them) using the basic Intuition (AmigaOS GUI) functionality would largely be handled in a separate high priority UI task. Keyboard and mouse input were handled by separate high priority handlers. Window rendering were given high priority.

Something as simple as the terminal / shell which in Linux is typically a terminal application talking to X, in AmigaOS consists of several components, each running in it's own task, some of them providing services that can be reused:

- an input handler, processing keyboard entry, which sends messages to the console device.

- The console device provides a stream oriented read/write interface that hooks a keyboard and mouse to a rectangular section of a Window (you can attach a console device to any window to get an ANSI/VT100 like terminal). It provides the text rendering, and "cooks" the keyboard input into escape sequences etc. It exchanges messages with the console-handler.

- The console-handler, which provides a higher level wrapper around the console.device, providing additional services such as command line editing, history, and manages the window the console.device is instantiated in. In AmigaOS you can open a console-handler by writing to the special filename CON: which will open a console window for you and give you a file handle to interact with it.

The shell is comparatively "dumber" than on Linux as a result of this structure, as the console-handler is expected to handle most stuff like line editing.

A typical AmigaOS app - even if the developer did not take care to thread the app explicitly - would usually end up splitting it's processing over many threads by virtue of making use of OS services that were explicitly message passing, and where stuff dealing with the UI would get priority.

It made it very easy to ensure the UI remained responsive, and was a cornerstone of a lot of the early OS friendly demos of Amiga features: Run whatever you wanted in multiple windows. The OS would still always prioritise the stuff that would make user-interaction feel snappy, unless you actively worked to prevent it (doing your own component rendering in your apps main thread, for example, like lots of modern software ends up doing by virtue of stupidly lazy frameworks...)