Hi Halim, On Wed, Sep 03, 2008 at 06:54:10PM +0200, Halim Sahin wrote:

Hallo, On Mi, Sep 03, 2008 at 05:55:07 +0200, Klaus Knopper wrote:

...

Das beobachtete Phänomen trat so ähnlich bei uns auch auf, daher habe ich die Cursorrouting-Funktion in SBL gepatcht, seither geht's.

Lieber Klaus, Du vermengst hier glaub ich mehrere dinge! Siehe Dir mal den Bug#497568 An. Das von Christian beschriebene Problem haben nicht sbl benutzer mit kernel 2.6.26 auch. Das Problem scheint mit der Nutzung diverse X Programme zusammenzuhängen.

Also ich habe aus seiner Mail nicht herausgelesen, das es sich um ein Problem mit X handelt. Wo steht das?

Das entfernen von wichtigen Funktionen kann eigentlich nicht zum Ziel führen.

Welcher "essentieller Funktionen"? Das aktuelle SBL verursacht einen internen Fehler, da sich das Programm jedemal im Speicher "vermehrt", wenn eine Cursorrouting-Taste gedrückt wird, um es einmal für Nicht-Techniker auszudrücken. Mein Patch ersetzt dies durch einen einfachen Funktionsaufruf. Dadurch wird das Cursorrouting bi uns überhaupt erst einmal brauchbar. Vorher stürzte es einfach ur ab, und zwar jedesmal, wenn eine Cursorrouting-Tsate gedrückt wurde. Ich weiß, bei dir nicht. Du hast ja auch eine andere Braillezeile ubnd verwendest eine andere Sprachausgbe, und überhaupt ist dein System anders. Aber bei uns war es eben so, und durch den Patch geht es jetzt. Ich habe keine Funktionalität "weggepatcht".

Ich hab Deinen patch probiert und festgestellt, das sbl dadurch unbrauchbar wird, was das routing angeht.

In welcher Form äußert sich das? Bei uns springt der cursor an die gewünschte Stelle, und es kommt nicht zu einem Absturz der Sprachaugabe. Vor dem Patch ging beides nicht. Das ist die konkrete Erfahrung. Wenn durch den Patch bei dir ein Problem auftritt, sollte es genau beschrieben werden, damit man es beheben kann. Marco hat schon angekündigt, dass er generell das Cursorrouting überarbeiten möchte, da es auch für ihn nicht richtig nachvollziehbarer, alter Code ist. Das sehr ich genauso. In der derzeitigen Form wundert mich sowohl, das es bei dir jemals fuinktioniert hat, als auch dass es "langsamer" werden sollte, wenn man den fork() weglässt und den Cursor RICHTIG positioniert.

Clickt man auf einen bereich, wo der cursor nicht hinkommen kann,oder auch mehrfach an irgendeine stelle blockiert die Funktion (ohne fork).

Bei uns passiert das nicht. Die Frage ist also, warum es bei dir passiert. In welchem Programm, beispielsweise?

Wenn dann innerhalb dieses Zeitraumes versucht wird über die Tastatur was zu schreiben, Dann zieht sbl den cursor immer weg, bis die blockierende Abarbeitung vorbei ist. Das ist so sicher kein Weg.

Wenn das bei dir so passiert, dann ist es ein Fehler, der behoben werden muss. Ich kann dir sagen, was in der fork()-Version passiert, wenn eine der ncurses-Funktionen blockiert, i.e. der Cursor sich nicht positionieren lassen will. Dann läuft ein Timer ab, der das laufende Programm killt (kein Witz), und der Programmfluss geht zurück zum aufrufenden Thread. DAS ist sicher keine elegante Lösung, stattdessen sollte erst gar nicht versucht werden, mit falschen x/y-Koordinaten zu positionieren, ODER es müssen non-blocking Aufrufe verwendet werden. Der fork war und ist an dieser Stelle auf jeden Fall falsch, da er sehr viele Seiteneffekte hat (Dateideskriptoren werden geschlossen, obwohl der Hauptprozess noch darauf zugreift, Variablen werden verdoppelt, das ganze System wird instabil). Daher meine Verwunderung, warum es mit dem fork() überhaupt jemals funktionieren konnte.

BTW. der code zum routing stammt von einem alten brltty und wird heute noch verwendet.

Sagte Marco auch, und ich finde, es ist Zeit, den Code loszuwerden und durch etwas gesunderes zu ersetzen. Vor allem, weil keiner mehr versteht, was der Code eigentlich genau macht. Das was er machen soll, lässt sich sicher mit viel weniger Zeilen Code programmieren.

Was Deine Probleme mit sbl angeht: Hast Du mittlerweile eine livecd, die bei Dir genau das Problem reproduziert?

Das Problem sehe ich durch den Patch als vorerst gelöst an, der Feher lag beim fork() nebst Schließen von Dateideskriptoren, die noch in Benutzung waren (nämlich durch die laufende Sprachausgabe), daher ist hier kein Debugging mehr notwendig. Der durch die Behebung dieses Fehlers zutage getretene systematische Fehler bei der Verwendung von Calls, die unter bestimmten Umständen (die ich hier noch nicht in der von dir gemeldeten Form nachvollziehen kann) ist der nchstem, den es zu beheben gilt. Einen Timer ablaufen zu lassen und das Programm zu terminieren, wenn es blockiert, kann ja wohl keine erstzunehmende Dauerlösung sein. Eine Cursorpositionierung muss auch ohne fork() nicht-blockierend möglich sein, das machen doch tausende von Konsolenprogrammen, warum soll sbl das nicht können? Viele Grüße -Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org