Mi a véleményetek? Ha nincs flock, a mkdir ugyanolyan jó lehet? Verseny helyzet melyiknél fordulhat elő nagyobb eséllyel?
Egyébként ahogy teszteltem, a flock leveszi a lock-ot a fájlról akkor is, ha kill-t kap a folyamat. Ez ugye nem áll fennt a mkdir esetében, ott félő hogy nem indul el a program többé, ha nem törli semmi a directory-t.
- log69 blogja
- A hozzászóláshoz be kell jelentkezni
- 1093 megtekintés
Hozzászólások
subscribe
- A hozzászóláshoz be kell jelentkezni
Nagyon jó! Fogom alkalmazni. Mindent leírtál a két módszerről, nincs mit hozzátenni. Ehhez a feladathoz szerintem egyformán jól a dolgát az flock és az mkdir (ezt eddig is használtam), azaz szerintem egyformán jó. Az flock abban jobb amit írtál, hogy az csak a memóriában létezik, a fájlrendszer "adminisztrálja" az adott PID-hez, és legvégső esetben automatikusan megsemmisül a PID-el együtt. Míg a létrehozott könyvtár ottmarad ha a processz valamilyen oknál fogva nem takarítja el.
- A hozzászóláshoz be kell jelentkezni
mi a helyzet a network fajlrendszerekkel (nfs, samba, stb)? az flock megy ott is?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Ahogy olvasom, NFS régóta támogatja flock-ot, és úgy látom Samba-nál is működik (nem teszteltem).
- A hozzászóláshoz be kell jelentkezni
bookmark
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
Én személy szerint se az mkdir se a touch $LOCKFILE módszereknek nem vagyok a híve megmondom miért: Sok olyan scriptet láttam, ami épp oda tette a lock file-ját ahova neki épp tetszett, és igen, néha előfordult, hogy azok ott maradtak. Csak hogy tetőzzük a problémát: Néha az eredeti script is eltűnt, míg a lock file ott maradt.. Na ilyenkor van az, hogy van egy árva file-od amiről azt se tudod ki fia-borja, és ha egy tényleg nagy rendszert üzemeltetsz, és egy ilyen szembe jön, akkor inkább jobb otthagyni, mert inkább foglaljon plusz helyet, mint sem valamit megboríts a file törlésével.
Ergo én személy szerint jobban preferálom a memóriában tárolt lockokat, vagy ha muszály FS szinten, akkor file-ba, de akkor a file tartalma igen is mondja el azt, hogy:
- Melyik script lock file-ja (lehetőleg a script lokációjával)
- Mikor jött létre
- Esetleg, hogy mi a fő scipt PID-je.
Tény, hogy macerább, de viszont szerintem bullet proof-abb mint az mkdir/touch-os megoldás.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
Ha jól értelmeztem őt az érdekelte, hogy az flock helyett az mkdir is alkalmas-e biztonságos zárolásra (például a versenyhelyzetek tekintetében). Alkalmas. Míg a "touch $LOCKFILE" az én eddigi ismereteim szerint távolról sem (de ha mégis lehet akkor érdekel, hogy hogyan). Az más kérdés, hogy minden FS lock hátránya a szemetelés, de a lényeg, hogy lehet biztonságosan zárolni az mkdir-el. Persze néha úgy marad, de az más kérdés. :)
- A hozzászóláshoz be kell jelentkezni
Ha ez a kérdés, akkor azt mondanám, hogy egy FS szintű lock sem biztonságos eléggé :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
Én úgy fogalmaznék inkább, hogy az mkdir-nek vannak hátrányai, de zárolni biztonságosan lehet vele, a touch meg semmire nem jó (SZVSZ). A kernel lock nyilván a legjobb, ha elérhető.
- A hozzászóláshoz be kell jelentkezni