Dotaz: cteni / zapis do souboru pro vice procesu, jazyk C

[ext3fs]

Zdravim,

 mam nasledujici dotaz. Pisu v jazyce C (pro linux) urcitou aplikaci. Je pravdepodobne, ze bude spustena vicekrat v danem case (nekolik procesu). Aplikace bude cist data ze souboru (text), ale muze obcas nastat situace, ze se v tomtez souboru provedou zmeny (pridani, nahrazeni, mazani). Zajimalo by mne, kdyz bude mit nekolik procesu tento soubor otevreno pro cteni a jiny proces otevre tentyz soubor pro zapis a provede zmeny

 

napr.: proces1 ma otevren soubor.txt pro cteni (je nastaven na pozici zacatku desateho radku), proces2 ma otevren soubor.txt pro zapis (maze desaty radek)...

 

jak se zachova proces1, ktery chce cist radek c.10,ale proces2 ho vymazal? A vymaze ho vubec?Jak mohu vedet, ktery proces dostane prioritu k provedeni sveho ukonu drive?

 

Resi tohle jadro a nebo libc automaticky a nebo se to musi v programu osetrit?

Dekuji za reakce.

 

Odpovědi

[kozzi]

IMHO ti to vubec nepojede, jelikoz pokud jeden program bude mit ten soubor.txt otevren, tak ten druhej pri pokusu o otevreni vrati chybovy stav.

[kozzi]

kecam

[pht]

Takhle to dělá jen bill (ano i tam jde nastavit sdílení, etc)

Ad původní dotaz: pokud to aplikace č.1 přečte dřív, než to aplikace č.2 zapsala, tak bude mít původní data, v opačném případě nová data. Jak je popsáno v jiných zápiscích, jde to řešit zámky, které ale nekontroluje libc ani jádro, nýbrž Vaše aplikace. Případně si na to můžete najít nějakou již hotovou knihovnu.

Jinak: nevím jaké povahy jsou vaše řádky, práce s variabilní délkou řádku je už sama o sobě dost opruz, nemluvě o sdílení. Nechcete spíš použít nějakou databázi, která už všechno umí, např. SQLite?

[ext3fs]

Potrebuji to mit prave v  textovem souboru. Jedna se o aplikaci (extreni content filter pro postfix) k filtrovani a kontrole posty.

Jedine co bude v txt souboru je seznam platnych emailovych adres v me domene.

adresa1@domena.cz

adresa2@domena.cz

. . .

Takze se da ocekavat, ze se tento soubor bude menit jen velmi malo (nova adresa / smazani stare adresy), nicmene

muze ke zmene dojit kdyz s nim bude zrovna jiny proces pracovat. Textovy soubor volim predevsim pro jednoduchost,

moznost editace / zobrazeni v jakemkoli editoru, atd.

[pht]

Tak si to skopírujte vedle, tam upravte a pak nový soubor přejmenujte na místo starého. Tím budou mít aplikace před změnou data před změnou a po změně nová data, vše v konzistentním stavu.

[Fuky]

To je zásadní chyba, tím nezajistí konzistentní data.

[pht]

Proč myslíte?

[Fuky]

Specifikaci sice vyžaduje, aby knihovní fce rename() byla atomická, ale nejsem si jistý zda-li to opravdu platí a hlavně jestli pro všechny filesystémy.

Když pomineme Linux, tak se najde určitě ještě spousta Unixů, které s tím mají problém On how rename is broken in Mac OS X.

Raději bych opravdu zvolil zamykací soubor.

[Michal Kubeček]

Konzistenci mít bude, ale nedozví se o změnách. Protože pokud ten soubor nezavře a neotevře znovu, bude pořád pracovat s tím původním (na který už nebude ukazovat adresářová položka), ne s tou upravenou a přejmenovanou kopií.

[pht]

To je pravda, ale z povahy zadání jsem předpokládal, že se tak stane. Buď ten mailový démon načte tu konfiguraci právě jednou a pak se stejně musí restartovat; nebo to čte při každém mailu a pak to funguje "samo". Ale nepředpokládám, že by udělal něco ve stylu: 1. otevřít, 2. přečíst, 3. seek na začátek, 4. přečíst...

[Michal Kubeček]

Tradiční řešení je načíst jednou na začátku a pak vždy jako reakci na HUP. Nebo by šlo využít některého z notify mechanismů.

[ext3fs]

Presne tak to delam. Ale i tak tady "velmi mala" sance je, ze program nacte neaktualni data.

[ext3fs]

Momentalni koncepce programu je takova, ze se spousti pro kazdy mail solo.

Premyslel jsem napsat to jako klient - server aplikaci, kdy serverova cast by drzela v

pameti konfiguraci a data a klient posilal veci ke zpracovani serveru. Tim by bylo

vse vyreseno,ale casova narocnost a vetsi komplikovanost (i vice moznych chyb) mne od toho odradila.

 

[Michal Kubeček]

Ono to zase tak složité není, jde jen o to si to jednou napsat. Jak už to jednou máte, už to můžete používat pro spoustu dalších aplikací.

[dustin]

A proč by externí filtr nemohl číst seznam adres z DB místo ze souboru?

[ext3fs]

Protoze proti DB (MySQL) se overuje pop3/smtp, s toutez DB pracuje i maildrop.

Nedovedu presne odhadnout jeji zatizeni (obcas v logu narazim na hlasku "Prilis mnoho spojeni." limit

je nastaven myslim na 200) takze dalsi komunikace s DB by znamenalo jeste vetsi zatez DB. Ale mozna

to bude nakonec jedine rozumne reseni.

[dustin]

Toho bych se nebál, mysql je pro takto jednoduché dotazy v pohodě. Režie bude minimální. Určitě spolehlivější, než se mořit se zamykáním souboru. Jedině snad opakované připojování do DB při každém běhu skriptu - možná popřemýšlet o nějakém serverovém poolu konexí, ale to už je velká komplikace.

[Fuky]

Musíš vyřešit spolupráci mezi procesy. Více informací nalezneš v knize Linux - Začínáme programovat, překlad 4. vydání (Neil Matthew, Richard Stones), originál v PDF druhého vydání [2,8MB]. Je tam pěkně popsané využívání souboru "zámku", který je vytvořen jedinou atomickou operací tj. flag O_EXCL a poté následuje vysvětlení a ukázky jak zamykat jen část souboru. Začíná to na straně 215.

[luky]

Ono to automaticky dost dobre ani nejde, musite si to osetrit sam podle vasich potreb.

[cronin]

Odporucam data storage - v tomto priapade subor - zakryt nejakou sluzbou poskytujucou pristup k v nom leziacim udajom. Ale ... neobjavujeme opat raz Ameriku - v tomto pripade databazu?