Das kann aber passieren, da die gesamte Operation nicht atomar ist. Der Kernel kann den Prozess durchaus zwischen der Abfrage der PIDs und der Abfrage der Prozesse schlafen legen. Wenn ein anderer Prozess während der Sleepphase nun einen langlebigen der Prozess erzeugt, für den der Kernel eine PID wiederverwendet, dann ist der mit dieser PID assozierte Job effektiv gesperrt.sma hat geschrieben:In wie fern ist da der Test, ob ein Worker noch lebt, eine Racing-Condition? Habe ich da einen Denkfehler?
Ich bestimme die Liste der (ID, PID) aus der Datenbank wo PID != NULL. Dies sind die aktiven bzw. hängen gebliebenden Jobs. Nun schaue ich, gruppiert nach PID, ob der Prozess noch lebt. Falls nein, ist das ein hängender Job und ich wiederbelebe alle diese Jobs, indem ich PID auf NULL setze. Was ich bei diesem Durchlauf nicht erwische - etwa weil ein Prozess gerade abnibbelt - das kommt beim nächsten Durchlauf in wenigen Sekunden oder Minuten dran. Was mir nicht passieren darf ist, dass eine PID vom OS wiederverwendet wird, sodass ich einen eigentlich toten Job für lebendig halte.
Es reicht imho nicht, nur zu prüfen, ob ein Prozess mit dieser PID noch lebt, man muss diesen Prozess auch als Worker identifizieren, z.B. in dem man ihn über ein Socket kontaktiert.
