Citat:
Dakle on puni baffer sa onime sto prima. U isto vreme ti ga praznis,
i sve je lepo dok ga ti brze praznis nego sto ga on puni. A kad on vise ne bude imao mesta.
Trabalo bi da prekine signal ready to receive (ili kako se vec tacno zove).
Ovo važi samo ukoliko se koristi handshaking. A i tada zavisi od toga koliki
je send buffer na strani centrale.
Ukoliko se handshaking ne koristi na samom čipu u PC-u postoji buffer, obično
veličine 16b, yavisno od čipa.
U svakom slučaju, ako bi ti petlja:
1. Pročitaš slog sa serijskog porta
2. Upišeš slog u bazu
3. goto 1
gubila bajtove, možeš da stvar rešiš pomoću producer/consumer šablona, sa
dva procesa od kojih jedan samo čita serijski port i sve pročitano smešta
u buffer (producer) i drugi koji bafer čita, parsira slogove i upisuje u bazu (consumer).
Producer i consumer mogu da budu niti (threads) kada buffer štitiš mutex-ima ili procesi gde buffer kreiraš i štitiš IPC objektima. Ako se odlučiš za procese, buffer možeš da napraviš i kao direktorijum na disku, gde producer radi na sledeći način:
1. Pročita slog sa serijskog porta
2. U direktorijumu kreira novi fajl sa jedinstvenim imenom (prefix A + timestamp + random), u njega upiše slog sa serijskog porta i zatvori fajl.
3. preimenuje fajl u B-timestamp-random
4. goto 1
Consumer radi ovako:
1. Pročita iz direktorijuma spisak fajlova koji počinju sa B (dakle kompletni slogovi)
2. Sve nađene fajlove pročita, parsira i prepiše u bazu.
3. sačeka 1s
4. goto 1
Drugom procesu možeš i da sniziš prioritet.
U svakom slučaju ovo je komplikovaniji način od proste petlje u jednom procesu i
više opterećuje procesor i disk, ali su operacije bolje raspoređene i smanjuje se
mogućnost da se nešto zagubi kada velika količina podataka nagrne na serijski port.