Ármány. Kártyádról több csomag özönöl, mint mit beletöltél.
Kis csomagelemző szoftverünk egy hálókártya driverről szedte le a csomagokat és dolgozta fel őket. Csak hát valamilyen rejtélyes okból kifolyólag a kimeneten sokkal több csomag volt mint amit a kártyára beérkezett. Aztán kiderült, hogy ugyanaz a csomag van jelen a kimeneten sokezer példányban, mert elvettük ugyan a hálókártyától a csomagokat, de nem jeleztük a drivernek, hogy elvettük és feldolgoztuk őket. Így aztán nagylelkűen újra és újra felajánlotta nekünk őket.
Ahhoz hogy, e néhány sor mély mondanivalóját teljes mértékbenfelfejtsükfeltétlenül szükséges megismerni az isteni szikrakipattanásánakkörülményeit. Naplófeljegyzésekből és egyébönéletrajzi irásokból tudjuk,hogy a költő, aki amúgy isnagyon nehezen viselte a munkahelyén töltöttpéntek estéket,a vers születésének előestéjén különös természeti jelenségrelett figyelmes. Felületes szemlélőnek talán fel sem tűnt volna,hogy a teljesen működőképsenek tűnő szoftver egy ideje semmikimenetetnem generál. Ez a jelenség azonban messze túlmutatottönmagán és a világfájdalmára érzékeny megfigyelőt északisarkcsillagként vezette ametafizika legsötétebb bugyraiba. A balsors lavináját az inditotta el,hogy homokszem kerülta gépezetbe és leállt a szoftver inputjaként szolgáló 4 filestream közül az egyik. Szoftverünk pedig epekedéstűl éssóvárgástúl elvakultan az üres streamre függesztettemélabús tekintetét,mit sem törődve a kihivóan domborodó,gyönyörűséggel kecsegtető többifilera. Ezt próbálta hát aszerző klasszikus formába önteni, a szoftvermegszemélyesitésével.
Következtetés:
Ha több erőforrást kezelsz egyszerre (socket, input file, megosztottmemória vagy bármi más), ne tegyél semmiképpen blokkoló függvényhívástolyan helyre, ahol az esetleges várakozás az egyéb szálak éserőforrások elérését megakadályozza.Tehát
ne kerüljön közösen használt nem reentráns függvényrészbe a lockok közé olyan függvény ami várakozhat, mert az az összes többi szálat megakaszthatja
ha több socketet vagy file-t olvasol szimultán soha ne várakozz ha az egyik közülük üres, mert ezzel megakadályozod a többinek az olvasását
ha egy mód van rá akkor ne használj végtelen ideig blokkoló függvényeket inkább adj meg nekik timeoutot, mert nem csak fenti jelenséget lehet így előállítani, hanem a szoftver vezérlését is elveszítheted
Applikációd hibára lel. Nem sejted mit rejt csomagod.
Hosszú ideje készítünk már TCP/IP/UDP és más protokol stackeken futó hálózati klienseket és elemzőket. Az elején végigböngésztük a megfelelő szabványt, annak alapján megírtuk a protokol feldolgozót, aztán hátradőlve vártuk, hogy minden a legnagyobb rendben menjen. És persze nem ment. Soha nem ment. Kivéve persze, ha mi írtuk mind a két végpontot, de hát ilyen véletlen szerencse ritkán adódik a fejlesztő életében. Mert ha a szabványtól el lehet térni, akkor a másik végpont el is fog és akkor gáz van. Feltéve, ha nem úgy írja az ember a klienst, hogy a szabványtól való esetleges eltérés az alapeset. Persze ez sem egy olcsó módszer, de sokszor még mindig olcsóbb, mint utólag egy külső megrendelőnél javítgatni.
Hogy memóriád véges, ne bánd. Csillan a részben az egész.
A Moore szabály szerint a processzorok/számítógépek kapacitása másfél évente megkétszereződik.Murphy törvényei szerint viszont a feldolgozandó adat mennyisége ezt mindig egy kicsivel meghaladó mértékben növekszik. Szóval vagy állandó versenyfutásban élsz az egyre növekvő igényekkel vagy pedig nincs más mód mint kiválogatni a feldolgozandó adatmennyiségből valamilyen reprezentatív/véletlenszerű mintát és beérni azoknak a kezelésével.
Kincs ami nincs a longint, ha pointered semmibe mutat.
Egy nagy C++ modulban a memóriahatékonyság miatt pointereket is szép számmal tartalmazó kisebb objektumot küldözgettünk át egy csomó feldolgozó osztályon. Közben persze elkövettük az ilyenkor lehetséges összes hibát:
megjegyeztük a stacken létrehozott változó címét
nem készítettünk a copy konstruktort az osztályhoz, aztán mégis másolgattuk az objetumokat
nem inicializáltuk a pointereket, aztán használtuk őket
tesztelés nélkül használtuk a null-pointereket éles bevetésen
és még számtalan egyebet is, mert ugye végtelen a pointerekkel összefüggő hibák tárháza. Mikor már elviselhetetlenné nőttek a karbantartási költségek egy nagyobb lélegzetvételű újraírás következett. Hosszabb tanakodás után persze egy referenciaszámláláson alapuló smart-pointer rendszer lett a befutó és azóta is szolgál mindenki megelégedésére. Messze behozta már a ráfordított költségeket.
Bár erős a vágy, nyílt socketet megnyitni nem tudsz soha már.
Tesztelés közben kérdésként hirtelen felmerült, vajh miért van az, hogy csak egy kis kódrészletet futtatva remekül sikerül egy socketen kommunikálni, míg ha az egész modult futtatjuk már a socket sem nyílik meg. Aztán persze az idő telik, a tantusz koppan. A socketet valaki egy másik kódrészletben megnyitotta már, dolgavégeztével pedig a lezárással nem fáradozott.
Áldott legyen a szoftver, csodás hibáink ébenfa tokja.
Az itt megjelenő haikuk egy valódi szoftverfejlesztő projekt melléktermékei. Kísérteties hasonlóságuk a valósággal egyáltalán nem véletlenszerű, mindegyik megtörtént eseményen alapul. Olyan hibák lenyomatai amiket mi elkövettünk és örülnénk ha te már nem követnéd el őket újra. Az az egyszerű igény szülte őket, hogy próbáljuk meg röviden és tömören megfogalmazni egy-egy hiba vagy egyéb tényállás lényegét, minimálisra csökkentve a kommunikációs üresjáratokat. Mi lenne erre alkalmasabb mint a haiku mindössze 3 sorban, 17 szótagban (5/7/5). Mostantól tehát közzé teszem az eddig született haikukat és próbálom folyamatosan 1-2 hetente frissíteni őket újabbakal.
Amennyiben valaki tud hasonló szoftverfejlesztéssel, távközléssel, hardverrel foglalkozó irodalomról vagy honlapról, kérem jelezzen.
