Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 10.
Quelques informations sur la stack graphique (app_server) et l'architecture des drivers pour les cartes vidéo:
https://www.haiku-os.org/tags/app_server
https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant
Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.