Out of curiosity, how is the kernel designed for responsiveness?
I assumed the reason for the responsiveness was actually because the GUI is multi-threaded and application developers are pushed into using multi-threading to an extreme? As an example I saw when reading somewhere, in Windows one Window is ran in a thread while in BeOS (which I imagine this carried over to Haiku) every individual GUI Object has its own thread. The example being that clicking a button in Windows could freeze the entire Window but clicking a button in BeOS would only freeze that particular button.
However, even with this approach – would it be the kernel providing this mechanism or some sort of a GUI layer? I still don’t have a very in-depth knowledge on Haiku’s architecture so feel free to correct me if I’m wrong.
Is there anything specific the Haiku kernel does for responsiveness that other modern kernels don’t do?
Maybe a little better use of custom priority levels that acutally have meaning… Supposely the scheduler is a tad weak still compared to Linux for some things but its not bad.
As an example I saw when reading somewhere, in Windows one Window is ran in a thread while in BeOS (which I imagine this carried over to Haiku) every individual GUI Object has its own thread. The example being that clicking a button in Windows could freeze the entire Window but clicking a button in BeOS would only freeze that particular button.
You are wrong. In Windows by default threre are only one thread for application with all it’s windows(but you can create additional threads and process windows in this threads). In BeOS and Haiku application and every window have it’s own thread. Also for each window threre are separate processing thread in app_server. This threads process graphics and messages. You can watch running threads in ProcessController application.
However, even with this approach – would it be the kernel providing this mechanism or some sort of a GUI layer? I still don’t have a very in-depth knowledge on Haiku’s architecture so feel free to correct me if I’m wrong.
GUI mechanism is implemented in user mode in app_server, input_server and registrar. Kernel don’t know anything about graphics(except splash screen during boot).
Is there anything specific the Haiku kernel does for responsiveness that other modern kernels don’t do?
For now all kernels are mostly similar and implement the same functionality, but diffrent kernels are optimized for diffrent purposes. Haiku kernel has special thread sheduler for responsiveness. It work on thread level, not on process level. Also Haiku kernel heavily use ports - commucation streams, that allow to transmit and receive data between kernel and programs or by diffrent programs. Ports are quite fast. For best speed Haiku drivers are divided into 2 parts: kernel part and user part. Kernel part simply give access to hardware and user part actually control hardware. For example 3D accelerated applications can use user driver(accelerant) in its own address space minimizing communication overhead.
So, from what I gather, the reason Haiku’s kernel is ‘designed for responsiveness’ is because its scheduler works on threads instead of processes and it has an effective message passing systems. Does that sound right?
Also as I know BeOS was first system, that can use SMP in efficient way. Scheduler is a main point. It can handle real-time and time-sharing threads with wide gradation of priorities. Threads with the same priorities are executed with same speed, if one thread have one bigger than other it’s speed will be doubled other thread speed. So thread execution speed is propotional to 2 in thread priority power. Real-time threads just take execution if active and there are no active real-time threads with higher priorities. If thread was unlocked by other thread it will be switched immediately. Sheduler quantum time is 3 milliseconds.
This is theory. Haiku can have bugs or incomplete implementation so lags can appear. For my look Haiku responsiveness is better than Windows. Windows Vista, 7 and 8 just freeze sometime for seconds I don’t know why. Linux kernel has notorious bug that cause system slowdown when IO activity is high.
I found an article how this works long time ago, but I forgot link.
Custom Kernel Design is best and reliable. Responsive makes it easy for developers and designer. Today as a developer never need to design your website especially for mobile and ipad devices.Further can visit this link: http://www.mobitsolutions.com/website-design-development.php
Ok i dint know where you got your informations from but they are mostly not true
The kernel isnt really “designed” for responsivness (not more than other developer did this for there os) also haiku is the most responsive desktop os i know (beside QNX and such exotic stuff)
It is also a question of definiton … what means responsiveness (if it means - low latency - then there ar better kernels out ther) But for haiku its own kernel is the best choice of course and a great peace of work from the developers :).
Not every GUI Element runs in its own thread.
Out of design every GUI App in Haiku/BeOS “normally” has two threads one for the app it self and one for the gui. Every app can easily add more threads eg. for data processing one for loading and so on.
You can see all thread if you look into the processcontroller in the Haiku Menu if you installed it in the deskbar.
(in this example the media_server with 6 threads)
Back in the days… every Windows / Linux program had “normaly” one thread for GUI (1…x windows), App and Dataprocessing. So if one them whent idle the whole App froze.
A nother thing was that you could define thread prioritys. So that Sound and video processing could be more prioritized.
Haiku arcitecture (not implementaion!!!) is not so much different from a nother modern operating system… its more a modular monolitic kernel (since BeOS put the netzwork code into kernel space… (waiting for correction form NoHaikuForMe :-D) bevore it was kind of a hybrid kernel design
Its a fun toppic - you can search throught the whole Forum to find funny fight about this …
It is strange to try to breathe life back into a thread after so many years.
Specifically, the Be API design requires that each BWindow have its own thread. Rather than a single event loop for the application, the design assumes each window gets a separate event loop, and traditionally each loop runs in its own thread. Fixing this would have been a bunch of work.
This will be true for very simple GUIs that have only a single window. If you look at an app with several windows open, there will be more threads. Almost always these extra threads are sat idle, just wasting resources.
Unlike the Haiku developers Be did not have the luxury of pushing releases back year after year, so very often they cut corners to get something out the door. Elaborate lies about why something is done, when the real answer is “It was quicker and we were in a hurry” are the foundation of BeOS mythology.
The problem isn’t that they “whent idle” but quite the opposite - they were busy. If a single-threaded app is busy doing something else then it isn’t handling events from its event loop and will appear unresponsive to the user. Adding more threads is not necessarily either sufficient or necessary for a solution. The key trick is that the UI should respond to the user as much as possible, and in a non-trivial application that can mean fundamental design choices have to be made differently rather than just hoping to solve everything by adding more threads.
Be’s design makes it easy enough to pass events off to another thread and seemingly not have to worry about them any more, but such buck-passing doesn’t actually solve the problem on its own. Somewhere the buck passing stops and the work must actually get done, and that work might block. So then the programmer has to design and implement how the application will behave while that worker thread is blocked. That, rather than spinning up extra event loops, is the bulk of the real work and BeOS doesn’t really help tackle it.
Let me give a simple and rather archaic but I hope instructive example. When burning a CD there is a “finalisation” step that often takes a noticeable amount of time and there are usually no “progress reports” from the CD writer during that step. Adding more threads to a program won’t speed up the finalisation, or allow the user to skip it, the programmer will in any case have to ensure that finalisation either completes or is safely aborted, and that the user is kept informed throughout. If the user tries to exit the application during finalisation, what should happen?
Actually the 2-threads model helps with this, somewhat. It is of course not a perfect solution (do you know one?).
The idea of the 2-thread model is that the window thread is always idle, so whenever the user decides to click a button or something similar, there is immediate feedback. This of course does not mean the operation will be performed any faster (quite the opposite: there is message passing overhead), but at least the window will be reactive and continue refreshing itself.
In the case of finalizing a CD, waiting on the CD drive can be done in the application thread. Meanwhile, the window thread is idle. This means you can, for example, close the window immediately. The app will receive a B_QUIT_REQUESTED message, but may not process it immediately. It will delay it until the CD is finalized and it gets to processing the messae. I think this is better than a frozen window where attempting to click a button will result in an hourglass cursor and a "does not reply" warning from the OS (and possibly no redrawing of the window contents). It is not a perfect solution, as you can still manage to fill the message buffer, but it solve the problem in the most common cases, at least.
I know it is possible to build applications in a similar way on other systems. But on BeOS and Haiku, it is mandatory and this forces developers to do things the "right" way. This comes at the cost of a few extra mostly idle threads, and in many cases there could be less of those (for example we could have a single thread handling all the windows).
But it worked to breaht some life back in “NoHaikuForMe” ;-). I initaly thought about mention hybrid kernel ;-). Welcome back :).
Actually - i just followed the forums modul on the left … and somehow this post showed up and i didnt looked a the age of the posts … - So i apologize.
I dont seed why someone would like to “fix” this except for a modal window. But i am open for some teaching here
[quote]
This will be true for very simple GUIs that have only a single window. If you look at an app with several windows open, there will be more threads. Almost always these extra threads are sat idle, just wasting resources. [/quote]
I dont see a downpoint there… either you waste ressources but get a fast responsivness or you save ressources and the whole system is slower. (just roughly explained) I know there is a lot of tweaking in between… But compared with other Systems … haiku isnt wasting so much more ressources than other ones.
Sorry to confuse idle and busy (lol) - happens to me all the time in my job ;-).
The thing is - in practical life it worked much better than on other operating systems … and it still seems to give the user much more satisfaction.
We had one guy in our computer science class who was brillant and inmplemented all software we had to write technical perfect (he was absolutly brillant!) … but the thing was - no one except him was able to use the programm.
So actually to conclude HaikuOS / BeOS might be not perfectly implemented (also i think its really well implemented and designed) it gives the user a really good expericene.
On the contrary I think it sends the message to beginning Haiku programmers that this is being solved for them but without actually solving most of their problems. It means all the examples assume your “2-thread model” which is probably healthy for a new programmer but there are no helping hands after that. If they do have multiple windows, perhaps without even realising it - they end up having to do a lot of thinking about concurrency that they didn’t ask for and which wouldn’t have been needed for a “2-thread model” program on other systems. And where they could use more threads, for example for a task pool where there’s a lot of independent tasks to be done and the OS could help out by providing that (whether something fancy like Grand Central Dispatch or just a basic built-in worker thread pool implementation) there is nothing at all in BeOS or Haiku so far as I can see.
Qt’s documentation advises programmers “try to avoid spawning new threads simply because you can” and I think that’s still sound advice in 2015 twenty years after Be ignored it.
with the prevalence of multicore systems, spawning threads is great advice, other wise we just waste those extra core. That a task itself may not be able to be paralleled does not mean that the application cannot perform other tasks, the entire idea of the BeOS threading model. Break out separate task to their own threads, and use messages etc to manage asynchronous data.
But it worked to breaht some life back in “NoHaikuForMe” ;-). 
- So i apologize.