| ![[View Software]](images/buttons/View Software.gif) ![[View Issues]](images/buttons/View Issues.gif) ![[View Issue]](images/buttons/View Issue.gif) | Type: | Suggestion | Severity: | Minor | | Status: | New | Status Comment: | | | Title: | Timberwolf help | | Version: | Timberwolf RC1 |
Navigate: 1-1
| tfrieden | - | 20120725 16:55 |  | Ein paar Kommentare dazu:
Wie kommst du auf die Idee, dass das RANDOM: die 100 % CPU-Auslastung produziert ? Die Tatsache, dass es gemounted ist bewirkt im Endeffekt nur, dass die places-Datenbank lÀuft. Es muss also nicht direkt mit RANDOM zusammenhÀngen...
Ich werde einfach mal die entsprechende Funktion so abÀndern, dass bei fehlendem RANDOM: die Psedo-Random-Zahlen der newlib benutzt werden. Dann kann man das tatsÀchlich testen (wird in rc2 sein)
Erster start:
Da ich sehr oft die geÀnderten Dateien von meiner Build-Machine auf den Testrechner zu laden bibn ich fast immer in der Situation, den TW *nicht* als erstes zu starten...
100 % Auslastung:
Die Datenbanken machen zwischendurch immer updates. Die neueste Version (rc2) geht einen anderen Weg, sqlite benutzt dann WAL (ich habe rudimentÀre "memory mapped files" implementiert). Vielleicht hilft das.
Es kann auch sein, dass im NSPR das polling der Sockets Probleme bereitet. Ich werde mir das bei gelegenheit noch ansehen.
| | |
|
Navigate: 1-1
|
|
