Mehrfachen Start einer Applikation verhindern - Konzept mit reinem C ohne Libs

**axeljaeger** · 25-08-2004, 19:55

Ich möchte den mehrfachen Start einer Applikation verhindern und zwar möglichst plattformunabhängig und mit wenig Abhängigkeiten. Idealerweise kann eine App der vorherigen Instanz eine Nachricht schicken, z.B: eine Datei zu öffnen. Da hab ich bisher folgende Lösungsansätze gesehen:

- Lockfile
- Socket aufmachen

Das erste ist ja sowas von unelegant: Wenn die Instanz abraucht und das Lockfile nicht löscht hat der Anwender den Ärger. Beim Socket hat man das Problem nicht und man könnte sogar noch eine Nachricht verschicken. Aber so 100%ig bin ich damit auch noch nicht zufrieden. Irgendwo hab ich jetzt was anderes gelesen, das basiert auf der Idee, dass eine shared-lib nur einmal vom System geladen werden soll. Bringt man nun eine statische Variabel in einer Lib unter, könnte man so die Instanzen zählen und evtl. über Callbacks auch Nachrichten verschicken. Da ich das nur sehr grob im Kopf hab, wie das funktionieren kann, würde ich gerne Meinungen dazu hören.

**TrollSlayer** · 25-08-2004, 21:28

Wie wärs wenn, die Applikation sich beim Start die Prozesstabelle anguckt und falls ein Prozess dieser Applikation schon läuft, der neue Prozess sich beendet? Ist vielleicht zu aufwendig. War nur so eine Idee

Gruß

**axeljaeger** · 25-08-2004, 21:40

Das ist nicht plattformunbhängig und meiner Meinung nach nicht sicher: Man kann da doch nur auf Namen überprüfen?

**panzi** · 26-08-2004, 11:09

PF_LOCAL sockets sind doch ok, oder warum nicht?

**axeljaeger** · 26-08-2004, 12:48

Zitat von panzi

PF_LOCAL sockets sind doch ok, oder warum nicht?

Was ist das genau und geht das ohne Libs auch auf Windows? Was spricht denn gegen die Lösung mit der Staticvariable in einer Lib, außer dass man keine große monolithische Exe mehr bauen kann?

**panzi** · 26-08-2004, 22:03

Zitat von axeljaeger

Was ist das genau und geht das ohne Libs auch auf Windows? Was spricht denn gegen die Lösung mit der Staticvariable in einer Lib, außer dass man keine große monolithische Exe mehr bauen kann?

Nun wegen das mit der lib: Naja, und dann hatt werd die lib mehrfach installiert, warum auch immer, in versch. Verzeichnissen und ruft die bin dann 2 mal mit anderen lib pfad auf...

PF_LOCAL wird auch PF_UNIX genannt. Sowas kann MS ganz einfach nicht untzerstützen... Mit cygwin gehts aber, ist da aber ein wrapper über PF_INET.
PF_LOCAL sind locale sockets, optimiert für IPC. Funken genauso wie alle anderen sockets, nur sind die addresen (bei benahmten sockets) Dateinamen.

Was aber bei solchen sockets blöd ist: Die Datei, die so ein socket representiert muss man auch mit remove() entferen. Jedoch kann man erkennen, ob die Lockfile "echt" ist, indem man versucht darüber kontakt mit dem damit verbundenen Prozess aufzunehmen. Wenn das net klappt, weiß man das es nen fehlerhaften Programmabbruch gab, was man bei normalen Lockfiles nicht erkennen kann.

**axeljaeger** · 27-08-2004, 09:00

Zitat von panzi

Nun wegen das mit der lib: Naja, und dann hatt werd die lib mehrfach installiert, warum auch immer, in versch. Verzeichnissen und ruft die bin dann 2 mal mit anderen lib pfad auf...

Wenn ich eine Lib an zwei Stellen liegen hab, wird sie auch zweimal geladen?
Damit könnte ich zur Not leben.

Zitat von panzi

Was aber bei solchen sockets blöd ist: Die Datei, die so ein socket representiert muss man auch mit remove() entferen. Jedoch kann man erkennen, ob die Lockfile "echt" ist, indem man versucht darüber kontakt mit dem damit verbundenen Prozess aufzunehmen. Wenn das net klappt, weiß man das es nen fehlerhaften Programmabbruch gab, was man bei normalen Lockfiles nicht erkennen kann.

Wie kann man über ein Lockfile mit einem Programm Kontakt aufnehmen?

**burst** · 27-08-2004, 09:23

ich wuerds vielleicht mit ner named pipe machen, das gibs unter windows und unter linux, aber wirklich plattformunabhaengig ist es natuerlich nicht. ich wage es auch zu bezweifeln das es sowas wirklich plattformunabhaengig ohne extra lib gibt. ne fifo muesstest du halt einmal fuer windows und einmal fuer linux implementieren und dann ein paar #ifdefs setzen...

**axeljaeger** · 27-08-2004, 09:30

Ihr mögt die Idee mit der shared-lib alle nicht hab ich das Gefühl.

**panzi** · 27-08-2004, 10:37

@axeljaeger
Lockfile ist hier das falsche Ausdruck. Es ist die "Adresse" des (server-)sockets. PF_LOCAL sockets verwenden eben Dateinamen als Adresse, macht auch sinn, ist sicher LOCAL.

@burst
Named pipes gibt's unter Windows? Das sit mir neu. Hast nen link dazu?

**axeljaeger** · 27-08-2004, 10:42

Wo ist denn der Unterschied zwischen einer Named Pipe und einem Local Socket?

**burst** · 27-08-2004, 10:51

Zitat von panzi

@burst
Named pipes gibt's unter Windows? Das sit mir neu. Hast nen link dazu?

http://msdn.microsoft.com/library/de...amed_pipes.asp

sind wesentlich komplizierter als unix fifos oder andere windows ipc methoden, aber sehr performant.

da faellt mir ein shared memory koennte man auch noch benutzen, gibs auch unter linux und unter windows

**axeljaeger** · 27-08-2004, 10:53

Bekommt man bei Windows nicht so und so einen Zeiger auf die Prev-Instance bei WinMain?

**panzi** · 27-08-2004, 22:24

Zitat von axeljaeger

Bekommt man bei Windows nicht so und so einen Zeiger auf die Prev-Instance bei WinMain?

Angeblich (lt. einen Lehrer von mir) nur unter win16, unter win32 ist das nur noch ein "fake" Parameter (abwärtskompatiblität). Bin aber eben was win angeht net so die Referenz (siehe auch mein unwissen bezügl. named pipes, da hab ich damals auch nur nach posix kompatieblen named pipes gesucht und eben nix gfunden).