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.