Results 1 to 13 of 13

Thread: MSN open source, your tcpclient desc.

  1. #1

    Exclamation MSN open source, your tcpclient desc.

    to (the author of the component and) anyone who uses the msn component from this forum:

    You should consider the way you are currently terminating your reader thread in your tidtcpclient desc. The way this terminate is coded is not vcl thread safe. If an exception occurs in the thread in combination with fire an event the you can have av's when calling vcl objects (like the mainform of your project where the component is dropped on, and you coded an event handler ondisconnect).

    Consider this for thread termination:
    [1] FreeOnTerminate:=False;
    [2] When terminating the thread:

    {* REMOVED: after av on close connection event fire
    if Assigned(FTCPClientReader) then
    FTCPClientReader.Terminate;}

    if Assigned(FTCPClientReader) then
    begin
    if not FTCPClientReader.terminated then
    begin
    if FTCPClientReader.suspended then FTCPClientReader.resume;
    FTCPClientReader.terminate;
    FTCPClientReader.waitfor;
    FTCPClientReader.free;
    FTCPClientReader := nil;
    end;
    end;

    Of course there are other solutions for this problem like, using messages (postmessage ...) or a more complex desc of the tidtcpclient.

    hopefully the solution makes sense otherwise do it your way, but i think you can get "unexpected av's" when doing so


    ANYWAYS: I THINK YOU HAVE DONE A GREAT JOB ! IT'S A GOOD EXAMPLE OF DELPHI OOP. Well done guy(s)

  2. #2
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    In Nederlands had ook gemogen hoor ... in ieder geval even verplaatst naar het NLDMSNP forum...
    Qui custodiet ipsos custodes

  3. #3

    sorry ouwe

    je hebt helemaal gelijk.

    als het wat waard is: zit hier alleen tussen mensen die geen ned spreken en we waren even bezig met o.a. die tcpclient bekijken. maar the english is nu over, mijn fout

  4. #4
    Pefect, leuk dat mensen zo mee denken.

    Heb je misschien de geweizigde versie voor mij of moet ik zelfde de wijzigingen doorvoeren?

    Mee helpen aan open-source is altijd leerzaam en makkelijk. Bedankt.

  5. #5

    Lightbulb Aan jou de eer

    Aan jou de eer om de wijzigen in jullie component door te voeren..

    Op zich is je tcpclient met reader thread goed opgezet. en zal goed werken als zodanig (in een engine like component). maar in combinatie met andere vcl's in het geval van exceptions die niet goed worden afgevangen kan de thread niet worden afgesloten omdat deze nog wacht op een notify of iets dergelijks(connectionclosedgracefully is ook een leuke die er weleens door heen glipt). Synchonize e.d. zaken is voor safe use of global resources alleen en niet voor problemen die kunnen ontstaan bij wachten als een ander component nog iets verwacht (AV's).

    BTW De IDTHREAD van indy zelf is beter geschikt voor gebruik in combinatie met de indy compos en andere vcls. Deze idthread bijv heeft een beforerun and afterrun om de thread execute heen en is speciaal gebouwd toen om het gebruik van threads en indy compos te faciliteren (geen onnodige herhaallus in de execute en wachten op events e.d. gaat makkelijker). De idthread is bijvoorbeeld op exceptions (de vaakvoorkomende bottleneck als niet afgevangen in de thread) en de afhandeling daarvan als de thread moet worden ge-terminated.

    maar er zijn nog veel meer mogelijkheden als gebruiken van custom messages e.d.

  6. #6
    Ik heb de fixes zoals hierboven proberen toe te passen maar helaas treedt er een dead-lock op bij het verbreken van de verbinding.
    Bij de contructor van de Thread heb ik FreeOnTerminate op False gezet.
    De Disconnect van de TCP client ziet er nu als volgt uit:
    Code:
    procedure TTCPClient.Disconnect;
    begin
      inherited Disconnect;
    
      if Assigned(FTCPClientReader) then
      begin
        if not FTCPClientReader.Terminated then
        begin
          if FTCPClientReader.Suspended then FTCPClientReader.Resume;
          FTCPClientReader.Terminate;
          FTCPClientReader.WaitFor;
          FreeAndNil(FTCPClientReader);
        end;
      end;
    end;
    Doe ik wat verkeerd ofzo?

  7. #7
    Dat heeft te maken met een indy exception (in dit geval een silent one) die je niet goed afhandelt in de thread.execute. De thread is in een lock geraakt omdat er een ConnectionClosedGracefully nog rondzweeft. Dit bedoelde ik overigens met ik gebruik liever IDThread voor de reader thread. Deze heeft al de loop ingebakken om onafgebroken te lezen en is BETER voor bereid op exceptions die in de thread plaatsvinden (de idthread heeft een onexception eventhandler...).

  8. #8
    Zal ik daar eens naar kijken. Kost het veel werk om het om te bouwen?

  9. #9
    Een suggestie voor het NIET gebruiken van idthread, maar om je bestaande TThread implementatie om te bouwen dus:

    Het de bedoeling dat je de thread niet zo HARD moet terminaten. Je kan ook de thread gewoon een loop laten uitvoeren en deze laten aflopen op een andere dan "Terminated" clausule. Daar de delphi threads OnTerminate naleminlijk niet anders doet dan aangeven wanneer een variable FTerminated op true staat. Dit zegt niets over of je al af bent van de thread!

    (mijn stelregels voor delphi threads de voorzichtigheid voor thread creation and termination is already taken care for you bij the borland crew, dus nog voorzichtiger omgaan met de thread is niet echt nodig. je moet gewoon weten wat je in de object method in dit geval thread.onexecute uitvoert. daar waar een exception kan optreden moet je er wel rekening mee houden en dat soort zaken zijn van dan meer van belang dan check of terminated en dergelijke "belangerijke" zaken van de thread)

    Dus moet je geen terminate en terminated proberen te gebruiken in de onexecute van je thread, rather let the thread run and finish as normally as possible. Hiermee bedoel ik probeer zelf te bepalen wanneer de thread moet aflopen, dus wanneer je de grote lees-lus moet verlaten is iets wat jij in control moet hebben (heb je thread namelijk niet meer in control dan krijg je geheid unexpected av's en meer van dat moois).

    In jouw onexecute zijn er een paar plekken waar een silent exception kan optreden (daar waar je disconnected connection wilt aanspreken). Als deze of andere exception optreed dan weet je in principe genoeg. verlaat nu de loop waarin je leest en ga verder in je except block. hier ga je netjes afchecken welke exception je bent tegengekomen en je voert de disconnect van de tcpclient uit wanneer je dat wilt.
    en dan vuur je een geweldige disconnected event af zodat jouw msn client er ook vanaf kan weten en er nu goed op kan reageren.

    75% van het werk is het uitbreiden van je except block met de check op disconnect by any means possible please, better safe then sorry... Dan pas de inherited disconnect uitvoeren dan pas de event voor echt ge-disconnected !

    Is niet echt veel werk denk ik in regels code, maar meer een even andere kijk op hoe je de thread kan gebruiken als onderdeel van een component rather then dat de thread een component op zich is die simpelweg gehookt is in de tcpclient component.

  10. #10
    aanpassingen voor je tcpclient:

    procedure DoDisconnectedEvent; virtual;
    +
    Een eigen event die je wilt afvuren voor het doorgeven van goede disconnected event.

    En het is in deze DoDisconnected waar je de thread wilt dumpen als hij is afgelopen en niet zo rudimentair in de overridden disconnect

  11. #11
    Je kunt met meerdere mensen aan een project werken hoor. Als Jelmer het goed vind kunnen we JustPassingBy een account geven op de FreeVCS server om zelf de aanpassingen te doen. Dit in de 'open source gedachte'.....
    Marcel

  12. #12
    Originally posted by Marcel
    Je kunt met meerdere mensen aan een project werken hoor. Als Jelmer het goed vind kunnen we JustPassingBy een account geven op de FreeVCS server om zelf de aanpassingen te doen. Dit in de 'open source gedachte'.....
    Ik vind dat natuurlijk goed, maar wil JustPassingBy dit wel? Het scheelt mij werk en kan er altijd van leren. Het is ook direct de reden waarom ik het open-source heb gemaakt. Andere mensen kunnen er kritisch naar kijken en eventueel helpen.

    Ik zou het zeer op prijs stellen.

  13. #13
    Nog een keer het probleem in kaart gebracht voor je:

    Je wilt in jouw msn component de ondisconnect event van de tcp client gebruiken. Want daardoor zal jouw component weten van de disconnect. Nu heb je de thread creation and termination geregeld in de events connect en disconnect. Dan wil je dus ook dat altijd bij een disconnect dat deze event gebruikt wordt.

    Nu de situatie:
    In jouw thread.onexecute trap je de exception die er optreed in de lees-lus. ok dat is goed. Maar welke exception is er nu opgetreden? bij sommige exceptions die er kunnen optreden wordt de disconnect event NIET automatisch door indy aangeroepen ! dit moet je zelf doen (het aanroepen van de dodisconnected) zodat je er van gegarandeerd kunt zijn dat de thread juist op nil is gezet.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Browser window | mini applicatie
    By bounze in forum Algemeen
    Replies: 50
    Last Post: 16-Oct-03, 16:17
  2. Open Source licenties - verschillen
    By Anders in forum Koffiehoek
    Replies: 4
    Last Post: 08-May-03, 10:22
  3. Welkom in mijn open source sectie
    By Marcel in forum Marcel
    Replies: 0
    Last Post: 31-Jan-03, 15:48

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •