You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
65 lines
3.4 KiB
65 lines
3.4 KiB
2006-08-07
|
|
Es gibt noch einen bug im exception handling. Ich kann im Moment noch
|
|
nicht genau sagen was passiert, evtl. ist es auch nur ein bug im testprogramm.
|
|
Jedenfalls bekomme ich eine Fehlermeldung von wegen THROW kann nur in
|
|
einem TRY-CATCH block aufgerufen werden wenn der stream_pool thread mit
|
|
exit beendet.
|
|
Ich weiß zur Zeit noch nicht ob dieser Fehler im Hauptthread oder im
|
|
stream_pool thread passiert, ich vermute aber im Hauptthread, da der
|
|
CATCH-Bereich des stream_pool threads ausgeführt wird.
|
|
|
|
Möglicherweise ist das aber auch ein genereller Bug im exception system,
|
|
der auftritt sobald man exit () in einem catch bereich nutzt. (Was eigentlich
|
|
auch nicht wirklich ne gute Idee ist (meistens jedenfalls)...trotzdem sollte
|
|
es möglich sein. im zweifelsfall durch eine eigene Funktion exc_exit oder so.
|
|
|
|
OK, der richtige excenv stack sollte selectiert werden...daran liegts nicht.
|
|
Trotzdem scheint es kein excenv mehr in diesem stack zu geben nachdem ich
|
|
in den CATCH Block von scot_stream_pool_main_loop gekommen bin.
|
|
|
|
AHA, die event_listener_fini methode throwed evtl. eine exception, und zwar
|
|
ganau dann wenn sie von ihrem eigenen main loop aufgerufen wurde. Was
|
|
hier passierte...allerdings schon aus dem CATCH Teil der main_loop
|
|
methode, wodurch kein excenv mehr da war.
|
|
Nachdem ich einen TRY-CATCH Block um den betreffenden Teil in
|
|
event_listener_fini gemacht habe war das Problem behoben.
|
|
|
|
--------------------
|
|
|
|
Der fs_watcher code funktioniert so nicht. Man kann von dem notify descriptor
|
|
leider nicht genau so lesen wie von einem file descriptor.
|
|
Ich werde also code in scot stream integrieren, der die besonderheiten
|
|
von inotify descriptoren berücksichtigt.
|
|
Schließlich soll scot stream genau für sowas eine abstraction liefern.
|
|
|
|
--------------------
|
|
|
|
2006-08-23
|
|
|
|
OK, fs-watcher mit inotify functioniert gröstenteils. Das heißt auf einer
|
|
single cpu maschine läuft es problemlos, auf meiner alten SMP Maschine kommt
|
|
der thread der die filesystem events überwacht ab und zu irgendwie in einen
|
|
busy loop oder so was, jedenfalls reagiert er nicht mehr und zieht nahezu
|
|
100% CPU time auf einer CPU.
|
|
|
|
---------------------
|
|
|
|
Und hier jetzt der Knüller des Jahrhunderts.
|
|
### select von winsock2 ist kein cancellation point ###
|
|
### und (noch besser) kann nicht unterbrochen werden ###
|
|
Unerwartete und nervig. Seit Winsock2 ist select nicht mehr unterbrechbar. Das
|
|
macht es quasi unbrauchbar für threads wenn diese von Zeit zu Zeit unterbrochen
|
|
werden sollen (z.B. damit der select in dem thread neu hinzugekommene
|
|
Verbindungen mit überwacht), es sei denn man setzt die threads in einen
|
|
asynchronous mode.
|
|
Außerdem nuss ich multiple threads für die socket verwaltung verwenden, da
|
|
windows select per default nur 64 sockets verwalten kann, was für einen server
|
|
geradezu lächerlich wenig ist, also benutze ich pro 64 sockets einen thread.
|
|
Im Moment suche ich nach einem Weg wie ich das Problem umgehen kann. Eine gute
|
|
Möglichkeit scheint zu sein, den socket an dem ich auf connections warte auch
|
|
in jedem select zu überwachen, dann sollte der select zurückkommen sobald eine
|
|
neue Verbindung hergestellt wird.
|
|
Dann muß nur noch sichergestellt sein das sich nur ein thread um die neu
|
|
ankommende Verbindung kümmert und das alle anderen solange warten bis der neue
|
|
socket in die zuständige socketliste eingetragen wurde. Das sollte aber mit
|
|
einer critical section kein Problem sein.
|