Ipari zen

Szak-irodalom. A fejlesztő jajszava haikuban. A technika ördöge avagy a lelketlen vasban a mélyen emberi.

A szoftverfejlesztés művészete és a zen

2010.01.29. 15:54 Ipari zen

Da-da-da-dadog a kártya

Címkék: driver hálókártya

Á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.

Szólj hozzá!

2010.01.22. 12:58 Ipari zen

A pesszimista szoftver

Címkék: select pesszimista timeout dead lock

Mi megvan, mit sem
ér. Mi nincs, arra szegezd
a tekinteted.
 

Ahhoz hogy, e néhány sor mély mondanivalóját teljes mértékben  felfejtsük  feltétlenül szükséges megismerni az isteni szikra  kipattanásának  körülményeit. Naplófeljegyzésekből és egyéb  önéletrajzi irásokból tudjuk,  hogy a költő, aki amúgy is  nagyon nehezen viselte a munkahelyén töltött  péntek estéket,  a vers születésének előestéjén különös természeti jelenségre  lett 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 semmi  kimenetet  nem generál. Ez a jelenség azonban messze túlmutatott  önmagán és a világ  fájdalmára érzékeny megfigyelőt északi  sarkcsillagként vezette a  metafizika legsötétebb bugyraiba.
A balsors lavináját az inditotta el,  hogy homokszem került  a gépezetbe és leállt a szoftver inputjaként szolgáló 4 filestream közül az egyik. Szoftverünk pedig epekedéstűl és  sóvárgástúl elvakultan az üres streamre függesztette  mélabús tekintetét,  mit sem törődve a kihivóan domborodó,  gyönyörűséggel kecsegtető többi  filera. Ezt próbálta hát a  szerző klasszikus formába önteni, a szoftver  megszemélyesitésével.

 

Következtetés:

Ha több erőforrást kezelsz egyszerre (socket, input file, megosztott   memória vagy bármi más), ne tegyél semmiképpen blokkoló függvényhívást   olyan helyre, ahol az esetleges várakozás az egyéb szálak és  erő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

 

Szólj hozzá!

2010.01.15. 12:42 Ipari zen

Borongós elmélkedés a szabványoknak nem megfelelő hálózati végpontokról

Címkék: szabvány kivétel konform non konform

 

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.

Szólj hozzá!

2010.01.08. 12:27 Ipari zen

Szelektív mintavételezés

Címkék: memória szelektív minta mintavételezés

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.

Szólj hozzá!

2010.01.03. 15:11 Ipari zen

Null pointer exception

Címkék: copy pointer constructor null exception smart pointer

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.

2 komment

2010.01.01. 23:22 Ipari zen

Socket error

Címkék: vágy error megnyitás socket

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. 

Szólj hozzá!

2010.01.01. 22:29 Ipari zen

Release Note

Címkék: release beköszöntő haiku indító

Á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.

1 komment