[Tk] Doppeltes starten abfangen und Wert übergeben (Graphische Oberflächen)

[thread]17159[/thread]

[Tk] Doppeltes starten abfangen und Wert übergeben

Tags: perl5 GUI Tk Similar Threads

Readers: 17

Articles: hide open all | hide show old branches

+15 replies
Kean

2012-02-15 15:31

User since
2004-08-18
463 articles
BenutzerIn

Ich bin gerade dabei ein Script zu basteln mit Tk und würde gerne irgendwie das doppelte Aufrufen verhindern. Also quasi bei jedem Start überprüfen ob ein Prozess mit dem gleichen Namen bereits existiert.
Wenn dieser bereits existiert will ich einen String übergeben und dann das zweite Script beenden.

Hat hier irgendjemand eine Idee wie das umgesetzt werden könnte? Oder so etwas ähnliches schonmal in der Perl/Tk Welt gesehen?
- +8 replies
- FIFO
  
  2012-02-15 17:44
  
  User since
  2005-06-01
  469 articles
  BenutzerIn
  
  Hi,
  betriebssystemunabhängig ist das nicht so trivial, unter Windows ist der Skriptname nicht in der Prozessliste. Ich schreibe meistens in einem BEGIN-Block ein kleines temporäres Lockfile, dessen Existenz sich ja prüfen lässt. Das Löschen gehört dann in einen END-Block. Einziger Nachteil: Bei einem Absturz ist das Lockfile evtl. persistent. Hier kann man aber über die Kontrolle der mtime Zeitintervalle vorsehen, nach deren Ablauf der Prozess als Zombie betrachtet und das Lockfile gelöscht wird.
  Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
  - +7 replies
  - GUIfreund
    
    2012-02-15 20:04
    
    User since
    2011-08-08
    559 articles
    BenutzerIn
    
    2012-02-15T16:44:20 FIFO
    Hi,
    betriebssystemunabhängig ist das nicht so trivial, unter Windows ist der Skriptname nicht in der Prozessliste. Ich schreibe meistens in einem BEGIN-Block ein kleines temporäres Lockfile, dessen Existenz sich ja prüfen lässt. Das Löschen gehört dann in einen END-Block. Einziger Nachteil: Bei einem Absturz ist das Lockfile evtl. persistent. Hier kann man aber über die Kontrolle der mtime Zeitintervalle vorsehen, nach deren Ablauf der Prozess als Zombie betrachtet und das Lockfile gelöscht wird.
    
    Den Absturz mit eval abfangen.
    Gruß
    GUIfreund
    - +6 replies
    - FIFO
      
      2012-02-15 20:24
      
      User since
      2005-06-01
      469 articles
      BenutzerIn
      
      2012-02-15T19:04:52 GUIfreund
      Den Absturz mit eval abfangen.
      
      Schon klar. Es gibt aber trotz allem immer noch Situationen, in denen das versagt (Stromausfall, Hardwareprobleme ...) und das Lockfile persistiert.
      Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
      - GwenDragon
        
        2012-02-15 20:36
        
        User since
        2005-01-17
        14848 articles
        Admin1
        
        Ja, bei Coredumps hilft auch kein END oder gar eval.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
      - +4 replies
      - jan
        
        2012-02-15 20:59
        
        User since
        2003-08-04
        2536 articles
        ModeratorIn
        
        In's lockfile die PID schreiben und die lockfile mit flock locken -- ein filelock sollte einen kompletten Systemcrash doch nicht überleben, oder?
        Also: wenn das neu gestartete Programm in einer Zeit Y keinen lock bekommt und die PID noch am leben ist, ist das Programm unter der PID am laufen.
        Müsste das nicht mehr oder weniger laufen? Mein client läuft zwar unter Windows, ich entwickel darunter aber so ziemlich nie.
        
        +3 replies
        
        Molaf
        
        2012-02-16 06:07
        
        User since
        2007-10-11
        119 articles
        BenutzerIn
        
        Code (perl): (dl )
        
        1 2 3
        
        use Fcntl qw(:flock); open FLOCKFILE, '>', $ENV{APPDATA}.'/lst.lock'; flock(FLOCKFILE, LOCK_EX|LOCK_NB) or do {print "ENDE: Eine Instanz laeuft derzeit schon.\n\n";exit;};
        
        So mache ich das immer, das Lock-File wird auch nicht gelöscht (wozu auch). Es bekommt immer genau eine Instanz den Zugriff. Funktioniert unter Win wie unter Linux.
        
        +2 replies
        
        Kean
        
        2012-02-16 08:51
        
        User since
        2004-08-18
        463 articles
        BenutzerIn
        
        Ich hab das mal ausprobiert und es scheint ganz gut zu funktionieren.
        
        Wie könnte ich jetzt aber im Fall dass es läuft dem bereits aktiven Prozess etwas übergeben??
        
        Molaf
        
        2012-02-16 09:31
        
        User since
        2007-10-11
        119 articles
        BenutzerIn
        
        Das mache ich immer ganz gerne mit einem UDP-Server und UDP-Nachrichten.
        Das liegt aber auch daran, dass ich das mal machen musste und es seit dem immer mal wieder von der Anwendbarkeit passt.
        Unter Unix könnte man Unix-Sockets nehmen, das würde auch gleich die Lock-Geschichte erledigen. Der UDP-Server belegt auch eine einzigartige Resource (den jeweiligen UDP-Server-Socket), das könnte ebenfalls als Alleinstellungsmerkmal herhalten.
        
        Vorteil UDP-Nachrichten: Selbst wenn der Server abschmiert, oder nie gestartet wurde läuft das Programm weiter (bei mir nur zum Monitoring, die Nachrichten durften auch ins leere laufen).
- pktm
  
  2012-02-16 00:42
  
  User since
  2003-08-07
  2921 articles
  BenutzerIn
  
  Also, es bringt auch seine Probleme mit sich, z.B. wenn das Programm abstürzt, aber man könnte doch auch irgendwo eine Datei ablegen, in der steht, dass das Programm bereits gestartet wurde. Die löscht man dann beim Beenden wieder. Z.B. ein Tempfile.
  Und wenn schon eins existiert, dann bringt man einen Dialog, ob man das Programm trotzdem starten möchte.
  
  Ach, ich seh gerade, das hat schon jemand vorgeschlagen :-s
  http://www.intergastro-service.de (mein erstes CMS :) )
- +5 replies
- rosti
  
  2012-02-16 08:59
  
  User since
  2011-03-19
  3603 articles
  BenutzerIn
  
  Ich würde im Script ganz einfach eine Datei aufmachen und auf den FH ein EX_LOCK setzen. Somit ist der gesamte Prozess atomar, fertig.
  
  PS/Edit: Weitere Prozesse können zwar gestartet werden, warten jedoch solange, bis der erste Prozess, welcher das EX_LOCK bekommen hat, diesen wieder freigibt.
  Last edited: 2012-02-16 09:05:49 +0100 (CET)
  http://blog.rolfrost.de/
  
  The art of steam.
  - +4 replies
  - Molaf
    
    2012-02-16 09:33
    
    User since
    2007-10-11
    119 articles
    BenutzerIn
    
    Ohne NonBlocking wartet aber jeder Prozess dann bis er das Lock kriegt. Wenn man 10 startet, hat einer das Lock, 9 warten und holen es sich dann hinternander weg.
    - +3 replies
    - rosti
      
      2012-02-16 12:42
      
      User since
      2011-03-19
      3603 articles
      BenutzerIn
      
      2012-02-16T08:33:07 Molaf
      Ohne NonBlocking wartet aber jeder Prozess dann bis er das Lock kriegt. Wenn man 10 startet, hat einer das Lock, 9 warten und holen es sich dann hinternander weg.
      
      Genau ;)
      
      Und wenn ein Prozess sowieso in der Queue steht, hat er geruhsam Zeit, mal in die Prozessliste zu schauen ....
      http://blog.rolfrost.de/
      
      The art of steam.
      - +2 replies
      - Molaf
        
        2012-02-16 12:46
        
        User since
        2007-10-11
        119 articles
        BenutzerIn
        
        Aber wenn er in der Quere steht, dann ist er geblockt, macht in der Zwischenzeit gar nichts :/
        
        rosti
        
        2012-02-16 13:07
        
        User since
        2011-03-19
        3603 articles
        BenutzerIn
        
        2012-02-16T11:46:03 Molaf
        Aber wenn er in der Quere steht, dann ist er geblockt, macht in der Zwischenzeit gar nichts :/
        
        Mist, stimmt ;)
        http://blog.rolfrost.de/
        
        The art of steam.

View all threads created 2012-02-15 15:31.