Login
Newsletter
Werbung

Thema: Aaron Seigo kritisiert Canonical

5 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von krake am Mo, 18. Februar 2013 um 15:55 #

Was Martin damit ausdrücken versucht ist dass das Problem mittels menschlichen Zutuns behoben werden muss.
Ein blockierender Aufruf kann leider oft nicht "von außen", z.B. durch einen anderen Thread, unterbrochen werden

Es ist daher notwendig, den blockierende Aufruf zu finden und durch etwas zu ersetzen, das eben nicht blockiert.

[
| Versenden | Drucken ]
  • 0
    Von harrald am Mo, 18. Februar 2013 um 16:09 #

    Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter. Präemptives Multitasking erlaubt es, während ein Prozess/Thread blockiert (und nicht nur dann), einen anderen auszuführen. Komplizierter wird es mit unterschiedlichen Prioritäten, das ändert jedoch nichts am Grundprinzip. In der Regel werden innerhalb der gleichen Anwendung Threads gestartet, um zeitaufwändige oder semantisch voneinander unabhängige Aufgaben nebenläufig (blockadefrei) auszuführen.
    Menschliches Zutun wäre an dieser Stelle völlig unnötig hätte man eine vernünftige Architektur: separate Prozesse.
    Das von Dir beschriebene Problem tritt mit Plasma hingegen trotzdem auf, weil sich alle Plasmoids einen Prozess (nebenbei: auch Adressraum!) teilen müssen.

    [
    | Versenden | Drucken ]
    • 0
      Von krake am Mo, 18. Februar 2013 um 16:28 #

      Das ist orthogonal zu dem was ich geschrieben habe.

      Die ansich gute Idee, zu erkennen wenn etwas blockiert und dies dann zu beenden/unterbrechen, bzw. den Benutzer um eine derartige Entscheidung zu bitten, bedarf der grundsätzlichen Möglichkeit dies zu tun.

      Nicht alle blockierenden Aufrufe können von einem anderen Thread oder Prozess aus unterbrochen werden.

      Selbst im Falle, dass alle Plasma Applets in separaten Prozessen geführt werden würden könnte man daher nicht immer deren Blockaden unterbrechen.

      [
      | Versenden | Drucken ]
      • 0
        Von harrald am Mo, 18. Februar 2013 um 17:07 #

        Auch das ist nicht ganz korrekt. Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter ;)
        Userspace Prozessen stehen abgesehen von Prioritäten nur wenige Möglichkeiten zur Verfügung das Scheduling zu unterbinden. Dies hat im Allgemeinen wenig mit irgendwelchen Nutzer-"Entscheidungen" zu tun.
        Selbst der Kernelspace ist heute mit zunehmender Anzahl von akzeptierten RT-Patches, und Threaded Interrupt handlern etc zu großen Teilen preemptive. Blockierendes Verhalten ist unerwünscht, und tritt bei sauberem Design selten auf. Was natürlich sein kann, ist das eine zwischen Prozessen gemeinsam genutzte Ressource ihre Kapazitäten erschöpft hat (Festplatten Bandbreite/, (KWIN / Xorg / DBUS)-CPU zu 100% ausgelastet,). Das ist jedoch *erheblich(!)* seltener der Fall, als ein temporärer Plasma-Freeze.

        Nochmal: userspace Prozesse sind praktisch immer unterbrechbar (wenn Du anderer Meinung bist, bin ich gespannt mehr über entsprechende Beispiele zu erfahren), und wenn sie sich ohne Not gegenseitig blockieren ist es ein Bug.

        [
        | Versenden | Drucken ]
        • 0
          Von krake am Mo, 18. Februar 2013 um 17:52 #

          Dies hat im Allgemeinen wenig mit irgendwelchen Nutzer-"Entscheidungen" zu tun.

          Das war auch nur ein Beispiel für eine etwaige Reaktion des "Watch-Dogs". D.h. nicht immer ist eine automatische Unterbrechung erwünscht, z.B. habe ich schon bei mehreren Browsern gesehen, dass sie bei langen JavaScript Laufzeiten die Möglichkeit des Unterbrechens anbieten und es nicht einfach nach Gutdünken selbst tun.

          Nochmal: userspace Prozesse sind praktisch immer unterbrechbar

          Schon, aber meistens im Sinne von vorrübergehenend aus dem Scheduling genommen.
          Sicher, viele (vermutlich die meisten) Systemaufrufe sind ansich unterbrechbar, d.h. haben EINTR als mögliche Rückkehrursache.

          Aber es gibt schon Gründe warum am Ende einer Systembeendigung zwei Stufen der Prozessbeendigung kommen, weil eben nicht alle Prozesse immer in der Lage sind auf das "BItte beenden" zu reagieren.

          Es gibt sogar Fälle, wo selbst das Betriebsystem einen Prozess nicht vollständig und sauber entfernen kann, siehe Zombie-Prozesse.

          [
          | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung