A mellékelt C programmal csak egy baj van, hogy a
gets()astdin-ről olvas be, azaz ahhoz, hogy ez a program bármit csináljon be kell pipe-olni neki az ASCII-artot, tehát nem standalone
Aha. Ilyenkor ezt szoktam ajánlani. ;)
program < asciiart.txt
Az a "visszakacsacsőr" olyat tesz, mintha a program ezt csinálta volna: openat(STDIN_FILENO,"asciiart.txt",O_RDONLY)
Tehát itt egy darab pipeline sincs. Ezt átirányításnak hívják.
Mivel csak a "program" és a shell vesz részt a Nagy Műveletben, ezért "standalone". (WTF standalone?)
Valójában a következő történik:
keyboard > (STDIN_FILENO) shell ((STDOUT_FILENO) ---> buffer > screen ; (STDERR_FILENO) > screen)
- program indításakor
keyboard > (STDIN_FILENO) program ((STDOUT_FILENO) ---> buffer > screen ; (STDERR_FILENO) > screen)
- átirányításkor
asciiart.txt > (STDIN_FILENO) program ((STDOUT_FILENO) ---> buffer > screen ; (STDERR_FILENO) > screen)
Persze a keyboard és a file elemhez is tarozik buffer, pontosan akkora, amekkora őket megilleti. Hacsak mást nem mondasz nekik. ;)
A shell és a program is ugyanazokat a fd-ket használja, de ez még viszonylag egyszerű eset. Ha sok program fut, akkor már érdemes úrrá lenni a kavarodáson.
írtad a
substr()függvényt; na az C-ben nincs
Ki hitte volna? ;)
De ilyen van:
buffer[j+1]=0;
puts(&buffer[i]);
Ami kb. megfelel a "print substr(buffer,i+1,j-i+1)" awk kifejezésnek.
De gondolom ez az fs-cache miatt van így. Valami retroplatformon biztos nagyobb lenne a különbség. :P
Hááát, ezt 10M alatt nem fogod megtudni. :-D
Az ilyen "írok-olvasok" feldolgozások általában egyenletes sebességgel futnak. Ugyanez több szálon sem problematikus. A feladat akkor kezdődik, ha sok adattal, több szálon, bonyolult feldolgozást és indexelést is kell végezni. Ilyenkor a legfontosabb a feladathoz hangolt diszk alrendszer és az io buffer (per stream) mérete. Jelentős diszk terhelésnél érdemes úgy hangolni a rendszert, hogy a több szál kicsivel hosszabb ideig fusson, mint az egy. ;)
A retroplatform alatt mit értsek? (C64 nem ér!)