Programování v UNIXu

Programov´ an´ı v UNIXu (NSWI015) verze: 5. u ńora 2015 (c) 2011 – 2015 Vladim´ır Kotal (c) 2005 – 2011 Jan Pechanec (c) 1999 – 2004 Martin Beran

SISAL MFF UK, Malostranské nám. 25, 118 00 Praha 1

• Toto jsou ofici´ aln´ı materi´ aly pro v´ yuku pˇredmˇetu Programov´ an´ı v UNIXu (k´ od pˇredmˇetu NSWI015) na Matematicko-fyzikáln´ı fakultˇe Univerzity Karlovy. • Tyto materi´ aly jsou uveˇrejnˇeny pod licenc´ı Creative Commons BY-NC-SA 3.0. Soubory k uk´ azkov´ ym pˇr´ıklad˚ um uvedené v´ yˇse jsou Public Domain, pokud v nich nen´ı uvedeno jinak. • Tento pˇredmˇet je 2/1, cviˇcen´ı bude jednou za dva t´ ydny. • Vˇsechny informace, které budete potˇrebovat, a materiály k pˇrednáˇsce jsou na http://mff.devnull.cz/, vˇcetnˇe aktuáln´ı verze tˇechto poznámkov´ ych slajd˚ u (http://mff.devnull.cz/pvu/slides/). Dˇ r´ıve, neˇ z zaˇ cnete materi´ aly pouˇ z´ıvat, pˇ resvˇ edˇ cte se, ˇ ze nen´ı novˇ ejˇ s´ı verze! • Uk´ azkové pˇr´ıklady jsou na http://mff.devnull.cz/pvu/src/, pokud se budu v pozn´ amk´ ach odkazovat na konkrétn´ı pˇr´ıklad, link zde uveden´ y slouˇz´ı jako koˇrenov´ y adres´ aˇr. • Je potˇreba se zapsat na cviˇcen´ı v ISu. • Z´ apoˇcet je za z´ apoˇctov´ y program. • Zkouˇska m´ a p´ısemnou a u ´stn´ı ˇcást. • Zkouˇset se bude to, co bude odpˇredneseno (kromˇe témat na vyplnˇen´ı pˇr´ıpadnˇe zbylého ˇcasu). Vˇetˇsina informac´ı je ve slajdech, ale ˇrada d˚ uleˇzit´ ych podrobnost´ı m˚ uˇze chybˇet.

1

• Pˇredpoklady: – Uˇzivatelsk´ a znalost UNIXu, programován´ı v shellu na u ´rovni pˇrednáˇsky ´ ,,Uvod do UNIXu” (NSWI095) – Znalost jazyka C – Znalost z´ akladn´ıch pojm˚ u teorie operaˇcn´ıch systém˚ u • Tento text je pr˚ ubˇeˇznˇe doplˇ nován, ChangeLog zaˇc´ıná na stranˇe 250. Upozornˇen´ı na chyby pros´ım pos´ılejte na [email protected].

Obsah • u ´vod, v´ yvoj UNIXu a C, programátorské nástroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupov´ a pr´ ava, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vláken • ??? - bude definov´ ano pozdˇeji, podle toho kolik zbyde ˇcasu

• Budeme se zab´ yvat hlavnˇe principy UNIXu a programován´ım pro UNIX pouze v jazyce C. • Pˇ redn´ aˇ ska je pˇ rev´ aˇ znˇ e o syst´ emov´ ych vol´ an´ıch, tj. rozhran´ım mezi uˇ zivatelsk´ ym prostorem a j´ adrem. • Pˇri popisu API se budeme drˇzet normy Single UNIX Specification, version 3 (SUSv3). Systémy, které tuto specifikaci podporuj´ı, mohou pouˇz´ıvat oznaˇcen´ı UNIX 03. V souˇcasné dobˇe (10/2011) jsou to posledn´ı verze systém˚ u Solaris, AIX, HP-UX a Mac OS X na r˚ uzn´ ych architekturách (http://www. opengroup.org/openbrand/register/xy.htm). • Pro konkrétn´ı pˇr´ıklady budu pouˇz´ıvat vˇetˇsinou systémy FreeBSD a Solaris.

2

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorsk´ e n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupov´ a pr´ ava, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vláken • ??? - bude definov´ ano pozdˇeji, podle toho kolik zbyde ˇcasu

Literatura v ˇ ceˇ stinˇ e 1. Skoˇcovsk´ y, L.: Principy a probl´ emy operaˇ cn´ıho syst´ emu UNIX. Science, 1993 2. Skoˇcovsk´ y, Ludˇek: UNIX, POSIX, Plan9. L. Skoˇcovsk´ y, Brno, 1998 3. Jelen, Milan: UNIX V - programov´ an´ı v syst´ emu. Grada, Praha 1993 4. Linux - Dokumentaˇ cn´ı projekt. Computer Press, 1998; http://www.cpress.cz/knihy/linux ˇ e 5. Herout, Pavel: Uˇ cebnice jazyka C. 2 d´ıly. Kopp, Cesk´ Budˇejovice, 2004 (4., respektive 2. pˇrepracované vydán´ı)

3

Ohlednˇ e unixu doporuˇ cuji sp´ıˇ se literaturu v anglick´ em jazyce. 1. Vˇsestrann´ y u ´vod do UNIXu, ale dost struˇcná; Skoˇcovsk´ y je autorem v´ıce ˇcesk´ ych knih o unixu, ale dnes jsou jiˇz v´ıce nebo ménˇe zastaralé. 2. Pokroˇcilejˇs´ı pohled, ale pˇredpokládá pˇredbˇeˇzné znalosti, m´ısty tˇeˇzko straviteln´ a. 3. Programov´ an´ı v C pro UNIX System V, práce se soubory a s procesy, System V IPC, nepopisuje napˇr. vlákna a s´ıtˇe. 4. O Linuxu bylo samozˇrejmˇe v ˇceˇstinˇe vydáno mnoho dalˇs´ıch knih. 5. Vynikaj´ıc´ı knihy o jazyce C.

Literatura - design a principy syst´ emu 1. Uresh Vahalia: UNIX Internals: The New Frontiers. Prentice Hall; 1st edition, 1995 2. Bach, Maurice J.: The Design of the UNIX Operating System. Prentice Hall, 1986 3. McKusick, M. K., Neville-Neil, G. V.: The Design and Implementation of the FreeBSD Operating System. Addison-Wesley, 2004 4. McDougall, R.; Mauro, J.: Solaris Internals. Prentice Hall; 2nd edition, 2006. 5. Linux Documentation Project. http://tldp.org/

Tyto knihy se zab´ yvaj´ı stavbou unixu, pouˇzit´ ymi algoritmy, strukturami apod., nejsou to kniho o programov´ an´ı pod t´ımto systémem. 1. Skvˇel´ a kniha, zab´ yv´ a se obecn´ ymi myˇslenkami UNIXu a porovnává systémy SVR4.2, 4.4BSD, Solarix 2.x a Mach. 12/2005 mˇelo vyj´ıt druhé, doplnˇené vyd´ an´ı. Po nˇekolika letech ˇcekán´ı pˇrestalo druhé vydán´ı figurovat v listingu na amazon.com, a tedy se budeme muset zˇrejmˇe sm´ıˇrit s t´ım, ˇze nevyjde. 2. Klasick´ a kniha o UNIXu, popis struktury a funkc´ı jádra UNIX System V Rel. 2, ˇc´ asteˇcnˇe i 3; pˇrestoˇze je to kniha z dneˇsn´ıho pohledu jiˇz zastaralá, lze ji poˇr´ ad jednoznaˇcnˇe doporuˇcit, protoˇze to je jedna z nejlepˇs´ıch knih, co byla kdy o UNIXu naps´ ana. V roce 1993 vyˇsel ˇcesk´ y pˇreklad, Principy operaˇ cn´ıho syst´ emu UNIX, SAS.

4

3. Popis struktury a funkc´ı j´ adra FreeBSD 5.2; tato kniha navazuje na klasickou knihu The Design and Implementation of the 4.4 BSD Operating System od stejného autora (resp. jeden ze ˇctyˇr, uveden´ y jako prvn´ı). 4. Nejlepˇs´ı kniha o operaˇcn´ım systému Solaris. Obsahuje podrobné informace o tom, jak tento systém funguje vˇcetnˇe nejnovˇejˇs´ıch vˇec´ı z verze 10 jako jsou z´ ony, Crypto Framework, DTrace, Least Privilege model a dalˇs´ı. 5. Domovsk´ a strana Linux dokumentaˇcn´ıho projektu.

Literatura - programov´ an´ı 1. Stevens, W. R., Rago, S. A.: Advanced Programming in UNIX(r) Environment. Addison-Wesley, 2nd edition, 2005. 2. Rochkind, M. J.: Advanced UNIX Programming, Addison-Wesley; 2nd edition, 2004 3. Stevens, W. R., Fenner B., Rudoff, A. M.: UNIX Network Programming, Vol. 1 – The Sockets Networking API. Prentice Hall, 3rd edition, 2004 4. Butenhof, D. R.: Programming with POSIX Threads, Addison-Wesley; 1st edition, 1997 5. unixové specifikace, viz http://www.unix.org 6. manu´ alové str´ anky (zejm. sekce 2, 3)

1. Pravdˇepodobnˇe nen´ı lepˇs´ı knihy o programován´ı pod unixem (neobsahuje s´ıt’ové programov´ an´ı, to je v knize 3). 2. Aktualizované vyd´ an´ı dalˇs´ı z klasick´ ych knih o programován´ı pod unixem. Obsahuje i s´ıt’ové programov´ an´ı a aˇc samozˇrejmˇe nen´ı tak podrobná jako spojen´ı knih 1 a 3, m˚ uˇze to b´ yt nˇekdy naopak v´ yhodou. Tuto knihu jednoznaˇcnˇe doporuˇcuji, pokud chcete nˇeco kupovat a chcete m´ıt pro zaˇcátek jen jednu knihu. Pokud bych ji mˇel charakterizovat jednou vˇetou, bylo by to, ˇze autor vid´ı a dok´ aˇze uk´ azat souvislosti, coˇz je velmi vzácná vlastnost. 3. Klasick´ a kniha o s´ıt’ovém programován´ı, jedna z nejlepˇs´ıch k tomuto tématu; existuje i druh´ y d´ıl UNIX Network Programming, Volume 2: Interprocess Communications, která se zab´ yvá komunikac´ı mezi procesy (roury, POSIX IPC, System V IPC, synchronizace vláken, RPC). 4. Velmi dobr´ a a podrobn´ a kniha o programován´ı s vlákny. 5. Domovsk´ a str´ anka posledn´ıch specifikac´ı rozhran´ı UNIXu. 5

6. Podrobn´ y popis jednotliv´ ych funkc´ı (v Linuxu bˇeˇznˇe ne zcela dostaˇcuj´ıc´ı; manu´ alové str´ anky v tomto systému jsou ˇcasto horˇs´ı kvality neˇz u systém˚ u ostatn´ıch). 7. Kniha, kter´ a se neveˇsla na slajd a která pˇrekraˇcuje obsah této pˇrednáˇsky: Gallmeister, B. R.: POSIX.4 Programmers Guide: Programming for the Real World, O’Reilly; 1st edition, 1995. V´ yborná kniha s krásnou ob´ alkou o real-time rozˇs´ıˇren´ıch POSIXu. Viz také strany 161 a 165. . . . a spousta dalˇs´ıch knih, online dokumentac´ı a internetov´ ych zdroj˚ u, posledn´ı dobou vych´ az´ı pomˇernˇe hodnˇe knih o Linuxu, zamˇeˇren´ ych na pouˇz´ıván´ı i programov´ an´ı. . . . jdˇete na http://www.amazon.com/ a zadejte kl´ıˇcové slovo “unix”. Pokud byste z Amazonu nˇeco kupovali, dejte pozor na to, ˇze mnoho knih má aktualizovan´ a vyd´ an´ı i po nˇekolika málo letech, nˇekdy i levnˇejˇs´ı neˇz ta p˚ uvodn´ı, kter´ a jsou vˇsak st´ ale na skladu a v on-line nab´ıdce; tak at’ zbyteˇcnˇe nekoup´ıte starˇs´ı vyd´ an´ı neˇz to aktu´ aln´ı. Nav´ıc se vyplat´ı zkontrolovat i u pˇr´ısluˇsného vydavatelstv´ı, ˇze nen´ı v brzké dobˇe naplánováno vydán´ı nové – tato informace nˇekdy na Amazonu je, nˇekdy ne. . . . na Amazonu se m˚ uˇze vyplatit nakoupit knihy z druhé ruky, protoˇze jsou ˇcasto v´ yraznˇe levnˇejˇs´ı neˇz knihy nové. Problém je, ˇze vˇetˇsinou nen´ı moˇzné je poslat ˇ ale mus´ı v´ pˇr´ımo do CR, am je nˇekdo pˇrivézt.

Literatura - historie UNIXu • Peter Salus: A Quarter Century of UNIX, Addison-Wesley; 1st edition (1994) • Libes D., Ressler, S.: Life With Unix: A Guide for Everyone, Prentice Hall (1989) • Open Sources: Voices from the Open Source Revolution, kapitola Twenty Years of Berkeley Unix From AT&T-Owned to Freely Redistributable; O’Reilly (1999); on-line na webu: http://oreilly.com/openbook/opensources/book/index.html . . . mnoho materi´ al˚ u na webu; ˇcasto vˇsak obsahuj´ıc´ı ne zcela pˇresné informace

• Kapitola o BSD Unixu z Open Sources napsaná Marshallem Kirk McKusickem je opravdu v´ yborn´ a.

6

(Pre)historie UNIXu • 1925 – Bell Telephone Laboratories – v´ yzkum v komunikac´ıch (napˇr. 1947: transistor) v rámci AT&T • 1965 – BTL s General Electric a MIT v´ yvoj OS Multics (MULTIplexed Information and Computing System) • 1969 – Bell Labs opouˇst´ı projekt, Ken Thompson p´ıˇse assembler, z´ akladn´ı OS a systém soubor˚ u pro PDP-7 • 1970 – Multi-cs ⇒ Uni-cs ⇒ Uni-x • 1971 – UNIX V1, a portován na PDP-11 • prosinec 1971 – prvn´ı edice UNIX Programmer’s Manual

• AT&T = American Telephone and Telegraph Company • Multics byl systém, kter´ y v´ yznamnˇe ovlivnil dalˇs´ı v´ yvoj operaˇcn´ıch systém˚ u. Obsahoval mnoho v té dobˇe inovativn´ıch myˇslenek, z nichˇz ale ne vˇsechny byly pˇrij´ım´ any kladnˇe. V´ yznamnˇe ovlivnil právˇe UNIX, kter´ y mnoho myˇslenek pˇrevzal a jeho nedostatky se naopak snaˇzil napravit. Hlavn´ı rozd´ıl byl asi ten, ˇze UNIX byl navrˇzen jako mnohem jednoduˇsˇs´ı systém, neˇz Multics. • po odchodu BTL z projektu Multics prodala GE svoji poˇc´ıtaˇcovou divizi firmˇe Honeywell vˇcetnˇe projektu Multics, kter´ y se pak pod jej´ı patronac´ı d´ ale aktivnˇe vyv´ıjel (virtu´ aln´ı pamˇet’, multiprocesory, . . . ), aˇz do roku 1985. Posledn´ı instalace Multics-u fungovala na kanadském Ministerstvu obrany (Canadian Department of National Defence) a systém byl napˇr´ıklad jeˇstˇe aktivnˇe pouˇz´ıv´ an pro vojenské operace bˇehem války v Perském zálivu. Definitivn´ı shutdown byl proveden 31. ˇr´ıjna 2000. V´ıce informac´ı je moˇzné nalézt na http://www.multicians.org. • pˇred poˇc´ atkem pr´ ace na v´ yvojovém prostˇred´ı pro PDP-7 napsal Thompson program Space Travel, kter´ y byl vyvinut na jiném prostˇred´ı (Honeywell 635) a na p´ asce pˇrenesen na PDP-7. • celkem bylo 10 edic´ı tohoto manuálu, koresponduj´ıc´ı deseti verz´ım UNIXu vznikl´ ych v BTL. • UNIX V1 nemˇel vol´ an´ı pipe !!!

7

• manu´ al pro verzi 1: http://man.cat-v.org/unix-1st/ Stoj´ı za to nahlédnout, jak jeho struktura ovlivnila vzhled dneˇsn´ıch manuálov´ ych stránek. • za povˇ simnut´ı stoj´ı, ˇ ze UNIX je zhruba o 10 let starˇ s´ı neˇ z DOS • systém Multics mˇel 9 hlavn´ıch c´ıl˚ u, jak popsáno v ˇclánku Introduction and Overview of the Multics System z roku 1965. Za nejzaj´ımavˇejˇs´ı c´ıl bych povaˇzoval poˇzadavek na nepˇreruˇsovan´ y bˇeh systému. • Multics byl napsan´ y v jazyce PL/I (Programming Language #1), tedy dˇr´ıve neˇz byl UNIX pˇrepsan´ y do C ! • Multicsu byl v roce 1980 udˇelen jako prvn´ımu systému level B2. Po nˇekolik let to byl jedin´ y systém s t´ımto bezpeˇcnost´ım levelem. • GE byla zaloˇzena v roce 1892 slouˇcen´ım dvou spoleˇcnost´ı, z nichˇz jedna byla Edison General Electric Company zaloˇzená roku 1879 Thomasem Alvou Edisonem (vyn´ alezce ˇz´ arovky, filmové kamery, . . . ); v souˇcasné dobˇe jej´ı dceˇrinné spoleˇcnosti pokr´ yvaj´ı mnoho oblast´ı, vˇcetnˇe dodávky jednoho ze dvou typ˚ u motor˚ u pro Airbus 380 nebo bankovnictv´ı. • PDP = Programmed Data Processor. Prvn´ı typ, PDP-1, se prodávala za $120.000 v dobˇe, kdy se jiné poˇc´ıtaˇce prodávaly za ceny pˇres milión. To byla také strategie fy DEC - pojem computer tehdy znamenal drahou vˇec, potˇrebuj´ıc´ı s´ al a t´ ym lid´ı, kter´ y se o to vˇsechno bude starat. Proto DEC své maˇsiny nenaz´ yval poˇc´ıtaˇci, ale pravˇe slovem PDPs. • PDP-11 je legend´ arn´ı maˇsina od firmy DEC, postupnˇe vznikaly verze PDP1 az PDP-16, kromˇe PDP-2, PDP-13. Existuj´ı PDP-11 systémy, které jeˇstˇe dnes bˇeˇz´ı, a také firmy, které pro nˇe vyrábˇej´ı náhradn´ı d´ıly.

8

Historie UNIXu, pokraˇ cov´ an´ı • u ńor 1973 – UNIX V3 obsahoval cc pˇrekladaˇc (jazyk C byl vytvoˇren Dennisem Ritchiem pro potˇreby UNIXu) • ˇr´ıjen 1973 – UNIX byl pˇredstaven veˇrejnosti ˇclánkem The UNIX Timesharing System na konferenci ACM • listopad 1973 – UNIX V4 pˇ reps´ an do jazyka C • 1975 – UNIX V6 byl prvn´ı verz´ı UNIXu bˇeˇznˇe k dostán´ı mimo BTL • 1979 – UNIX V7, pro mnohé “the last true UNIX”, obsahoval uucp, Bourne shell; velikost kernelu byla pouze 40KB !!! • 1979 – UNIX V7 portován na 32-bitov´ y VAX-11 • 1980 – Microsoft pˇr´ıch´ az´ı s XENIXem, kter´ y je zaloˇzen´ y na UNIXu V7

• ACM = Association for Computing Machinery, zaloˇzena 1947. UNIX pˇredstavili Ken Thompson a Dennis Ritchie. • akt pˇ reps´ an´ı UNIXu do jazyka C byl moˇ zn´ a nejv´ yznamnˇ ejˇ s´ım momentem v historii tohoto syst´ emu ⇒ UNIX mohl b´ yt mnohem jednoduˇseji portov´ an na jiné architektury • na verzi 6 je zaloˇzena legend´ arn´ı kniha A commentary on the Unix Operating System, jej´ıˇz autorem je John Lions. • Microsoft neprod´ aval XENIX pˇr´ımo, ale licencoval ho OEM v´ yrobc˚ um (Original Equipment Manufacturer) jako byl Intel, SCO a jin´ı. Jiné firmy pak XENIX d´ ale portovaly na 286 (Intel) a 386 (SCO, 1987). Na webu je moˇzné naj´ıt zaj´ımavé informace popisuj´ıc´ı tuto dobu a tehdy kladn´ y vztah Microsoftu k UNIXu. • UNIX V7 mˇel cca 188 tis´ıc ˇrádek zdrojového kódu v cca 1100 souborech (zjiˇstˇeno pomoc´ı find, wc a awk pˇres soubory se jménem *.[cshy]). • pokud v´ as v´ıce zaj´ım´ a historie unixu, pod´ıvejte se na Wikipedii na heslo “unix” a skrz odkazy m´ ate na dlouho co ˇc´ıst. • V roce 1973 byl UNIX v´ıceuˇzivatelsk´ y systém (konta s hesly) s podporou pro multiprocessing s ochranou proces˚ u a stránkován´ım. Mˇel signály, roury, hierarchick´ y systém soubor˚ u s mount pointy, souborová práva (User/group/other r/w/x), hard linky, zaˇr´ızen´ı pˇr´ıstupná jako soubory. Kernel byl napsán v jazyku C a v pamˇeti zab´ıral jeho obraz 26 Kilobyt˚ u. Pro práci se soubory slouˇzily systémov´ a vol´ an´ı open(), close(), read(), write(), seek(), 9

pipe(). K manipulaci s procesy volán´ı fork(), exec(), wait(), exit(). Celkem bylo 48 syscall˚ u, z nich existuje 35 do dneˇsn´ı doby.

Divergence UNIXu • pol. 70. let – uvolˇ nov´ an´ı UNIXu na univerzity: pˇredevˇs´ım University of California v Berkeley • 1979 – z UNIX/32V (zm´ınˇen´ y port na VAX) poskytnutého do Berkeley se vyv´ıj´ı BSD Unix (Berkeley Software Distribution) verze 3.0; posledn´ı verze 4.4 v roce 1993 • 1982 AT&T, vlastn´ık BTL, m˚ uˇze vstoupit na trh poˇc´ıtaˇc˚ u (zak´ az´ ano od roku 1956) a pˇr´ıcház´ı s verz´ı System III (1982) aˇz V.4 (1988) – tzv. SVR4 • vznikaj´ı UNIX International, OSF (Open Software Foundation), X/OPEN, . . . • 1991 – Linus Torvalds zahájil v´ yvoj OS Linux, verze jádra 1.0 byla dokonˇcena v r. 1994

• UNIX je univerz´ aln´ı operaˇcn´ı systém funguj´ıc´ı na ˇsiroké ˇskále poˇc´ıtaˇc˚ u od embedded a handheld systém˚ u (Linux), pˇres osobn´ı poˇc´ıtaˇce aˇz po velké servery a superpoˇc´ıtaˇce. • UNIX V3 = UNIX verze 3, UNIX V.4 = system 5 release 4 atd., tj. UNIX V3 != SVR3. • UNIX System III tedy nen´ı UNIX V3; v této dobˇe (pozdn´ı 70. léta) bylo v BTL nˇekolik skupin, které pˇr´ısp´ıvaly do v´ yvoje UNIXu. Vx verze byly vyv´ıjeny v r´ amci Computer Research Group, dalˇs´ı skupiny byly Unix System Group (USG), Programmer’s WorkBench (PWB). Dalˇs´ı vˇetv´ı UNIXu byl Columbus UNIX téˇz v r´ amci BT. Na tˇechto r˚ uzn´ ych verz´ıch je právˇe zaloˇzena verze System III. Z´ ajemce o v´ıce informac´ı odkazuji na web. • UNIX se rozˇstˇepil na dvˇe hlavn´ı vˇetve: AT&T a BSD, jednotliv´ı v´ yrobci pˇrich´ azeli s vlastn´ımi modifikacemi. Jednotliv´ e klony od sebe navz´ ajem pˇ reb´ıraly vlastnosti. • System V R4 mˇel cca 1.5 milionu ˇrádek zdrojového kódu v cca 5700 souborech (zjiˇstˇeno pomoc´ı find, wc a awk pˇres soubory se jménem *.[cshy]). • Univerzita v Berkeley z´ıskala jako jedna z prvn´ıch licenci UNIXu v roce 1974. Bˇehem nˇekolika let studenti (jedn´ım z nich byl Bill Joy, pozdˇejˇs´ı zakladatel firmy Sun Microsystems a autor C-shellu) vytvoˇrili SW bal´ık Berkeley Software Distribution (BSD) a prodávali ho v roce 1978 za $50. Tyto poˇcáteˇcn´ı 10

verze BSD obsahovaly pouze SW a utility (prvn´ı verze: Pascal pˇrekladaˇc, editor ex ), ne systém ani ˇz´ adné jeho zmˇeny. To pˇriˇslo aˇz s verz´ı 3BSD. verze 4BSD vznik´ a roku 1980 jiˇz jako projekt financovan´ y agenturou DARPA a veden´ y Billem Joyem. Trp´ı problémy spojen´ ymi s nedostateˇcn´ ym v´ ykonem a vznik´ a tak vyladˇen´ y systém 4.1BSD dodávan´ y od roku 1981. • 4.1BSD mˇelo b´ yt p˚ uvodnˇe 5BSD, ale poté, co AT&T vzneslo námitky, ˇze by si z´ akazn´ıci mohli plést 5BSD se systémem System V, pˇreˇslo BSD na ˇc´ıslován´ı 4.xBSD. Bˇeˇznou vˇec´ı bylo, ˇze neˇz psát vlastn´ı kód, v´ yvojáˇri z Berkeley se radˇeji nejdˇr´ıve pod´ıvali kolem, co je jiˇz hotové. Tak BSD napˇr´ıklad pˇrevzalo virtu´ aln´ı pamˇet’ z Machu a nebo NFS-kompatibiln´ı kód vyvinut´ y na jedné kanadské univerzitˇe. • v´ yrobci hardware dod´ avali varianty UNIXu pro své poˇc´ıtaˇce a komercializace tak jeˇstˇe zhorˇsila situaci co t´ yˇce diverzifikace totoho systému • v 80-t´ ych letech se proto zaˇcaly objevovat snahy o standardizaci. Standard ˇr´ık´ a, jak m´ a vypadat systém navenek (pro uˇzivatele, programátora a správce), nezab´ yv´ a se implementac´ı. C´ılem je pˇrenositelnost aplikac´ı i uˇzivatel˚ u. Vˇsechny systémy totiˇz z d´ alky vypadaly jako UNIX, ale pˇri bliˇzˇs´ım prozkoumán´ı se liˇsily v mnoha d˚ uleˇzit´ ych vlastnostech. System V a BSD se napˇr. liˇsily v pouˇzitém filesystému, s´ıt’ové architektuˇre i v architektuˇre virtuáln´ı pamˇeti. • kdyˇz v roce 1987 firmy AT&T a Sun (jehoˇz tehdejˇs´ı SunOS byl zaloˇzen´ y na BSD) spojily svoje u ´sil´ı na vyvinut´ı jednoho systému, kter´ y by obsahoval to nejlepˇs´ı z obou vˇetv´ı, kromˇe nadˇsen´ ych reakc´ı to vzbudilo i strach u mnoha dalˇs´ıch v´ yrobc˚ u unixov´ ych systém˚ u, kteˇr´ı se báli, ˇze by to pro obˇe firmy znamenalo obrovskou komerˇcn´ı v´ yhodu. Vzniká proto Open Software Foundation (nezamˇen ˇovat za FSF), a zakládaj´ıc´ımi ˇcleny byly mimo jiné firmy Hewlett-Packard, IBM a Digital. Z toho vzeˇsl´ y systém OSF/1 ale nebyl pˇr´ıliˇs u ´spˇeˇsn´ y, a dod´ aval ho pouze Digital, kter´ y ho pˇrejmenoval na Digital UNIX. Zaj´ımavost´ı je, ˇze systém je postaven´ y na mikrojádru Mach. Po akvizici Digitalu Compaqem byl systém pˇrejmenován na Tru64 a s t´ımto jménem je dále podporov´ an firmou Hewlett-Packard, která se v roce 2002 s Compaqem spojila. Mezit´ım firmy AT&T a Sun kontrovaly zaloˇzen´ım UNIX International. Toto obdob´ı pˇrelomu 80-t´ ych a 90-t´ ych let se naz´ yvá Unix Wars – boj o to, co bude “standardn´ım unixem”. • OSF a UI se staly velk´ ymi rivaly, ale velmi rychle se stˇretly s neˇcekan´ ym protivn´ıkem - s firmou Microsoft. • (1992) 386BSD zaloˇzené na Networking Release 2 ; Bill Jolitz vytvoˇril 6 chybˇej´ıc´ıch soubor˚ u a dal tak dohromady funkˇcn´ı BSD systém pro i386. Tento systém se stal z´ akladem systém˚ u NetBSD a FreeBSD (a dalˇs´ıch, z tˇechto dvou systém˚ u vych´ azej´ıc´ıch). • (1995) 4.4BSD-Lite Release 2, po které následuje rozpuˇstˇen´ı CSRG, která skoro 20 let pilotovala v´ yvoj BSD vˇetve. V´ıce jiˇz zm´ınˇená kapitola o BSD Unixu.

11

Souˇ casn´ e UNIXy Hlavn´ı komerˇcn´ı unixové systémy: • Sun Microsystems: SunOS (nen´ı jiˇz dále vyv´ıjen), Solaris • Apple: Mac OS X • SGI: IRIX • IBM: AIX • HP: HP-UX, Tru64 UNIX (Compaq) • SCO: SCO Unix • Novell: UNIXware Open source: • FreeBSD, NetBSD, OpenBSD • Linux distribuce

• Striktnˇe technicky vzato se jako UNIX m˚ uˇze oznaˇcovat pouze systém, kter´ y proˇsel certifikac´ı Single Unix Specification. Z v´ yˇse uvedeného seznamu by to byly 4 operaˇcn´ı systémy, které byly registrovány jako UNIX 03 na r˚ uzn´ ych architektur´ ach (http://www.opengroup.org/openbrand/register/). Ostatn´ı systémy, které nebyly certifikovány, se oznaˇcuj´ı jako Unix-like, aˇckoliv v mnoha pˇr´ıpadech splˇ nuj´ı vˇetˇsin˚ u poˇzadavk˚ u standardu. Bˇeˇznˇe se nicménˇe pouˇz´ıvá oznaˇcen´ı Unix pro obˇe dvˇe skupiny. • kdyˇz jsem cca v roce 1998 projel nmapem vˇsechny DNS root servery, abych zjistil na kter´ ych systémech bˇeˇz´ı, bylo 80% z nich na SunOS/Solaris. IRIX je zase systém, kter´ y po mnoho let ovládal televizn´ı/filmov´ y pr˚ umysl (napˇr. Pixar studio kde na IRIXu vznikly filmy jako A Bug’s Life, Toy Story a dalˇs´ı). A na AIX napˇr´ıklad bˇeˇzel Deep Blue, paraleln´ı superpoˇc´ıtaˇc, kter´ y v roce 1997 porazil v ˇsesti fascinuj´ıc´ıch zápasech 3.5 ku 2.5 u ´ˇraduj´ıc´ıho velmistra ˇsachu Garriho Kasparova. Jin´ ymi slovy – kaˇzd´ y systém má svoje u ´spˇechy. • jak jiˇz bylo zm´ınˇeno, Tru64 UNIX vycház´ı z OSF/1 firmy DEC. Ta pˇredt´ım dod´ avala Ultrix, zaloˇzen´ y na BSD unixu. • OpenSolaris byl projekt vznikl´ y v ˇcervnu 2005 a byl zaloˇzen na podmnoˇzinˇe zdrojov´ ych text˚ u v´ yvojové verze Solarisu (kernel, knihovny, pˇr´ıkazy). Distribuce vzeˇslé z komunity jsou napˇr´ıklad LiveCD BeleniX, SchilliX a Nexenta. Pˇrestoˇze projekt OpenSolaris jiˇz dále nepokraˇcuje, existuje open source fork Illumos a na nˇem zaloˇzené distribuce SmartOS a OpenIndiana. • pozor na to, ˇze Linux je pouze jádro, ne systém, na rozd´ıl tˇreba od FreeBSD. Illumos je nˇeco mezi t´ım, jádro + drivery, základn´ı pˇr´ıkazy a knihovny, 12

a v bin´ arn´ı podobˇe to m´ a nˇeco pˇres 100MB. V obou pˇr´ıpadech je tedy spr´ avné pouˇz´ıvat spojen´ı “Linux (Illumos) distribuce”, kdyˇz se bav´ıme o celém systému. • kaˇzd´ a komerˇcn´ı varianta vycházela z jednoho ze dvou hlavn´ıch systém˚ u – UNIX V nebo BSD, a pˇrid´ avala si své vlastnosti. D´ıky mnoha verz´ım UNIXu tak vznik´ a velk´ y poˇcet r˚ uzn´ ych standard˚ u (strana 15). Nakonec se vˇetˇsina v´ yrobc˚ u shodla na nˇekolika základn´ıch. • graf zn´ azorˇ nuj´ıc´ı historii unixov´ ych systém˚ u a závislosti mezi nimi na 19-ti A4 listech ve form´ atu PS/PDF je k nalezen´ı na http://www.levenez.com/unix/

13

Standardy UNIXu • SVID (System V Interface Definition) – ,,fialov´ a kniha”, kterou AT&T vydala poprvé v roce 1985 – dnes ve verzi SVID3 (odpov´ıd´ a SVR4)

• POSIX (Portable Operating System based on UNIX) – série standard˚ u organizace IEEE znaˇcen´ a P1003.xx, postupnˇe je pˇrej´ım´ a vrcholov´ y nadn´ arodn´ı org´ an ISO

• XPG (X/Open Portability Guide) – doporuˇcen´ı konsorcia X/Open, které bylo zaloˇzeno v r. 1984 pˇredn´ımi v´ yrobci platforem typu UNIX

• Single UNIX Specification – standard organizace The Open Group, vzniklé v roce 1996 slouˇcen´ım X/Open a OSF – dnes Version 3 (SUSv3), pˇredchoz´ı Version 2 (SUSv2) – splnˇen´ı je nutnou podm´ınkou pro uˇzit´ı obchodn´ıho n´ azvu UNIX

• z´ akladn´ı informace je, ˇze oblast standard˚ u t´ ykaj´ıc´ı se unixov´ ych systém˚ u je vˇec znaˇcnˇe sloˇzit´ a a na prvn´ı pohled velmi nepˇrehledná. • AT&T dovolila v´ yrobc˚ um naz´ yvat svoji komerˇcn´ı UNIX variantu “System V” pouze pokud splˇ novala podm´ınky standardu SVID. AT&T také publikovala System V Verification Suite (SVVS), které ovˇeˇrilo, zda dan´ y systém odpov´ıdá standardu. • POSIX (Portable Operating System Interface) je standardizaˇcn´ı snaha organizace IEEE (Institute of Electrical and Electronics Engineers). • SUSv3 je spoleˇcn´ y standard The Open Group, IEEE (Std. 1003.1, 2003 Edition) a ISO (ISO/IEC 9945-2003). • Pro certifikaci operaˇcn´ıho systému na Single Unix Specification je nutné aby systém (na dané architektuˇre, napˇr. 64-bit x86) proˇsel sadou test˚ u. V´ ysledky test˚ u jsou pak vyhodnoceny. Testy samotné jsou sdruˇzeny do tzv. test suites, coˇz jsou sady automatick´ ych test˚ u, které projdou systém a zjist´ı jestli splˇ nuje rozhran´ı dané normou. Pro SUSv3 je takov´ ych test suites cca 10. • Rozhran´ı specifikované normou POSIX.1-2008 se dˇel´ı na 4 základn´ı skupiny: XSH (System Interfaces), XCU (Shell and Utilities), XBD (Base definitions). Z nich je co do poˇctu rozhran´ı nejobsáhlejˇs´ı XSH, která popisuje v´ıce neˇz 1000 rozhran´ı. • Skupiny rozhran´ı POSIXu spolu se skupinou Xcurses, která je souˇcást´ı Single Unix Specification (ale nikoliv souˇcást POSIX báze v normˇe IEEE Std 1003.12001) zahrnuj´ı celkem 1742 rozhran´ı, které tvoˇr´ı Single Unix Specification 14

(2003). Tabulky rozhran´ı SUS je moˇzné z´ıskat zde: http://www.unix.org/ version3/inttables.pdf • komerˇcn´ı UNIXy vˇetˇsinou sleduj´ı Single UNIX Specification, splnˇen´ı této normy je pr´ avˇe podm´ınkou pro uˇzit´ı názvu UNIX (znaˇcka UNIX 98 odpov´ıdá SUSv2, znaˇcka UNIX 03 odpov´ıdá SUSv3). Je postavena na bázi POSIXu. My se budeme drˇzet SUSv3. Popis datov´ ych struktur a algoritm˚ u jádra v tomto materi´ alu bude vˇetˇsinou vycházet ze System V Rel. 4. • na Solarisu je obs´ ahl´ a manu´ alová stránka standards(5), kde m˚ uˇzete na jednom m´ıstˇe nalézt mnoho informac´ı t´ ykaj´ıc´ı se standard˚ u. Jednotlivé pˇr´ıkazy splˇ nuj´ıc´ı danou normu jsou nav´ıc um´ıstˇeny do vyhrazen´ ych adresáˇr˚ u. Napˇr. program tr je v adres´ aˇr´ıch /usr/xpg4/bin/ a /usr/xpg6/bin/, v kaˇzdém je verze pˇr´ıkazu splˇ nuj´ıc´ı danou normu. Na pˇrep´ınaˇce a chován´ı dané normou se pak lze spolehnout napˇr. pˇri psan´ı shellov´ ych skript˚ u. • opˇet na Solarisu, pod´ıvejte se na hlaviˇckov´ y soubor /usr/include/sys/feature tests.h

POSIX • tvrzen´ı “tento systém je POSIX kompatibiln´ı” nedává ˇzádnou konkrétn´ı informaci – asi podporuje POSIX1990 a moˇzná i nˇeco dalˇs´ıho (co?) • dotyˇcn´ y bud’ nev´ı co je POSIX nebo si mysl´ı, ˇze to nev´ıte vy • jedin´ a rozumn´ a reakce je otázka “jak´ y POSIX?” • POSIX je rodina standard˚ u • prvn´ım dokumentem je IEEE Std POSIX1003.1-1988, pozdˇeji po vzniku dalˇs´ıch rozˇs´ıˇren´ı neformálnˇe odkazovan´ y jako POSIX.1 • posledn´ı verze POSIX.1 je IEEE Std 1003.1, 2004 Edition – obsahuje v sobˇe jiˇz i to, co dˇr´ıve definoval POSIX.2 (Shell and Utilities) a r˚ uzná, dˇr´ıve samostatná rozˇs´ıˇren´ı

• prvn´ım dokumentem je IEEE Std POSIX1003.1-1988, dˇr´ıve oznaˇcovan´ y prostˇe jako POSIX, pak odkazovan´ y jako POSIX.1, protoˇze POSIXem se nyn´ı m´ın´ı sada vz´ ajemnˇe souvisej´ıc´ıch standard˚ u. POSIX.1 v té dobˇe obsahoval programovac´ı API, tj. práce s procesy, signály, soubory, ˇcasovaˇci atd. S mal´ ymi zmˇenami byl pˇrevzat organizac´ı ISO (ISO 9945-1:1990 ), a je oznaˇcovan´ y i jako POSIX1990. IEEE oznaˇcen´ı je IEEE Std POSIX1003.1-1990. Tento standard byl s´ am o sobˇe velk´ yu ´spˇech, ale stále jeˇstˇe nespojoval tábory System V a BSD, protoˇze v sobˇe napˇr´ıklad nezahrnoval BSD sockety nebo 15

IPC (semafory, zpr´ avy, sd´ılená pamˇet’) ze System V. Souˇcást´ı standardu je i “POSIX conformance test suite (PCTS)”, kter´ y je volnˇe k dispozici. • oznaˇcen´ı POSIX vymyslel Richard Stallman, tedy ˇclovˇek, kter´ y v roce 1983 zaloˇzil GNU projekt. • d˚ uleˇzit´ a roˇzˇs´ıˇren´ı k IEEE Std 1003.1-1990 (jsou souˇcást´ı IEEE Std 1003.1, 2004 Edition): – IEEE Std 1003.1b-1993 Realtime Extension, neformálnˇe znám´ y jako POSIX.4, protoˇze to bylo jeho p˚ uvodn´ı oznaˇcen´ı pˇred pˇreˇc´ıslován´ım; j´ a budu toto rozˇs´ıˇren´ı nˇekdy také naz´ yvat POSIX.4. Vˇetˇsina tohoto rozˇs´ıˇren´ı je nepovinn´ a, takˇze tvrzen´ı “systém podporuje POSIX.1b” má jeˇstˇe horˇs´ı vypov´ıdac´ı hodnotu neˇz “systém je POSIX kompatibiln´ı”, a to prakticky nulovou. Jediná povinná ˇcást POSIX.4 je malé doplnˇen´ı k sign´ al˚ um oproti POSIX1990. Je proto nutné vˇzdy uvést, co z POSIX.4 je implementov´ ano – napˇr. sd´ılená pamˇet’, semafory, real-time signály, zamyk´ an´ı pamˇeti, asynchronn´ı I/O, ˇcasovaˇce atd. – IEEE Std 1003.1c-1995 Threads, viz strana 219. – IEEE Std 1003.1d-1999 Additional Realtime Extensions – IEEE Std 1003.1j-2000 Advanced Realtime Extensions, viz strana 240. – ... • standardy POSIX je moˇzné nalézt na http://www.open-std.org/. HTML verze je volnˇe k prohl´ıˇzen´ı, za PDF verzi se plat´ı.

Jazyk C • témˇeˇr cel´ y UNIX je napsan´ y v C, pouze nejniˇzˇs´ı strojovˇe z´ avisl´ a ˇc´ ast v assembleru ⇒ pomˇernˇe snadná pˇrenositelnost • navrhl Dennis Ritchie z Bell Laboratories v roce 1972. • n´ asledn´ık jazyka B od Kena Thomsona z Bell Laboratories. • vytvoˇren jako prostˇredek pro pˇrenos OS UNIX na jiné poˇc´ıtaˇce – siln´ a vazba na UNIX. • varianty jazyka: – p˚ uvodn´ı K&R C – standard ANSI/ISO C • u ´ spˇ ech jazyka C daleko pˇ res´ ahl u ´ spˇ ech samotn´ eho UNIXu

16

• CPL ⇒ BCPL ⇒ B (Thompson, interpret) ⇒ C • K&R C – jazyk C tak, jak je popsan´ y v klasické knize Brian W. Kernighan, Dennis M. Ritchie: The C Programming Language (Prentice-Hall, 1978). • v roce 1983 ANSI (American National Standards Institute) zformoval v´ ybor pro vytvoˇren´ı C standardu. Po dlouhém a pracném procesu byl v roce 1989 standard koneˇcnˇe hotov, a je znám´ y nejˇcastˇeji jako “ANSI C”, pˇr´ıpadnˇe jako C89 (napˇr´ıklad pˇrekladaˇc pro tuto normu se v Sun Studiu jmenuje c89, jelikoˇz i to samotné jméno programu mus´ı b´ yt podle normy). Druhé vydán´ı K&R knihy (1988) je jiˇz upravené právˇe pro nadcházej´ıc´ı ANSI C. V roce 1990 bylo ANSI C adoptov´ ano organizac´ı ISO jako ISO/IEC 9899:1990; tento C standard tak m˚ uˇze b´ yt nˇekdy oznaˇcován i jako C90. • se C standardem se pak nˇejakou dobu neh´ ybalo, aˇz na konci 90-t´ ych let proˇsel dalˇs´ı reviz´ı v r´ amci ISO a vzniká ISO 9899:1999, ˇcastˇeji oznaˇcovan´ y jako C99. V roce 2000 pak naopak tento standard pˇrevzal ANSI. • rozd´ıly mezi C89 a C99 jsou mimo jiné zahrnut´ı inline funkc´ı, definic´ı promˇenn´ ych napˇr´ıklad i do for konstrukce, jednoˇrádkov´ ych komentáˇr˚ u pomoc´ı //, nov´ ych funkc´ı jako snprintf apod. • specifikaci C standardu a mnoho dalˇs´ıch otevˇren´ ych standard˚ u je moˇzné nalézt na http://www.open-std.org/.

Form´ aty dat • poˇrad´ı bajt˚ u – z´ avis´ı na architektuˇre poˇc´ıtaˇce big endian: 0x11223344 =

11

22

33

44

addr +

0

1

2

3

–

little endian: 0x11223344 =

44

33

22

11

addr +

0

1

2

3

–

• ˇr´ adky textov´ ych soubor˚ u konˇc´ı v UNIXu znakem LF (nikoliv CRLF). Vol´ an´ı putc(’\n’) tedy p´ıˇse pouze jeden znak. • big endian – SPARC, MIPS, s´ıt’ové poˇrad´ı bajt˚ u • little endian – Intel

17

• velk´ y pozor na v´ ystupy program˚ u typu hexdump, které defaultnˇe vypisuj´ı soubor v 16-ti bitov´ ych ˇc´ıslech, coˇz svád´ı vidˇet soubor jinak, neˇz jak je opravdu zapsan´ y na disku; viz pˇr´ıklad (i386, FreeBSD). Prvn´ı ˇc´ıslo v souboru je znak ’i’, kter´ y ale reprezentuje niˇzˇs´ıch 8 bit˚ u 16-ti bitového ˇc´ısla, takˇze pokud vyp´ıˇseme prvn´ı 2 bajty jako short integer, mus´ı b´ yt reprezentace znaku ’i’ (tj. ˇc´ıslo 69) aˇz za 6a. Obdobnˇe pro ’kl’. $ echo -n ijkl > test $ hexdump test 0000000 6a69 6c6b 0000004 je samozˇrejmˇe moˇzné pouˇz´ıt jin´ y formát v´ ystupu: $ hexdump -C test 00000000 69 6a 6b 6c 00000004 • UNIX norma pˇr´ıkaz hexdump nemá, ale definuje od (octal dump), takˇze zde je jeho hexdumpu ekvivalentn´ı formát v´ ypisu na SPARCu (Solaris); vˇsimnˇete si zmˇeny oproti v´ ypisu pod FreeBSD! $ od -tx2 test 0000000 696a 6b6c 0000004

Deklarace a definice funkce • K&R – deklarace n´ avratov´ y_typ indentifik´ ator(); – definice n´ avratov´ y_typ indentifik´ ator(par [,par...]) typ par;... { /* tˇ elo funkce */ }

• ANSI – deklarace n´ avratov´ y_typ indentifik´ ator(typ par [,typ par...]); – definice n´ avratov´ y_typ indentifik´ ator(typ par [,typ par...]) { /* tˇ elo funkce */ }

18

• pouˇz´ıvejte pouze novˇejˇs´ı (ANSI) typ deklarac´ı a vˇzdy deklarujte prototypy funkc´ı, tj. inkludujte hlaviˇckové soubory. V´ yjimkou m˚ uˇze asi jen to, pokud budete pracovat s k´ odem, kter´ y byl napsan´ y podle K&R. • r˚ uzn´ ymi z´ apisy deklarac´ı se dostáváme rovnou i k r˚ uzn´ ym styl˚ um psan´ı zdrojov´ ych text˚ u. Nˇekteré systémy to pˇr´ıliˇs neˇreˇs´ı (Linux), jiné systémy maj´ı velmi striktn´ı pravidla pro psan´ı zdrojov´ ych text˚ u (napˇr. Solaris, viz on-line C Style and Coding Standards for SunOS : http://hub.opensolaris. org/bin/download/Community+Group+on/WebHome/cstyle.ms.pdf). Snad kaˇzd´ y UNIXov´ y systém m´ a program indent(1), kter´ y vám pomoc´ı pˇrep´ınaˇc˚ u pˇreform´ atuje jak´ ykoli C zdrojov´ y text do poˇzadovaného v´ ystupu.

C style • vˇec zd´ anlivˇe podˇradn´ a, pˇritom extrémnˇe d˚ uleˇzitá – u ´prava zdrojov´ ych k´ od˚ u programu • mnoho zp˚ usob˚ u jak ano: int main(void) { char c; int i = 0; printf("%d\n", i); return (0); }

• u C stylu je nejd˚ uleˇzitˇejˇs´ı to, aby byl konzistentn´ı. Pokud skupina program´ ator˚ u pracuje na jednom projektu, nen´ı zas aˇz tak d˚ uleˇzité, na jakém stylu se dohodnou (pokud je alespoˇ n trochu rozumn´ y), ale aby se dohodli. Jednotn´ y a dobˇre zvolen´ y styl ˇsetˇr´ı ˇcas a brán´ı zbyteˇcn´ ym chybám.

19

C style (cont.) • mnoho zp˚ usob˚ u jak NE (tzv. assembler styl): int main(void) { int i = 0; char c; printf("%d\n", i); return (0); } • nebo (schizofrenn´ı styl): int main(void) { int i = 0; char c; if (1) printf("%d\n", i);i=2; return (0); }

• pamatujte na to, ˇze dobr´ y styl zdrojov´ ych kód˚ u je i vizitkou programátora. Kdyˇz se v r´ amci pˇrij´ımac´ıch pohovor˚ u odevzdávaj´ı i ukázkové kódy, tak hlavn´ı d˚ uvod pˇrekvapivˇe nen´ı ten, aby se zjistilo, ˇze vám dan´ y program funguje. ´ Uprava samotného zdrojového textu je jedn´ım z kriteri´ı, protoˇze to pˇrenesenˇe m˚ uˇze svˇedˇcit i o dalˇs´ıch skuteˇcnostech – nˇekdo napˇr. bude odhadovat, ˇze pokud p´ıˇsete neˇcist´ y a neupraven´ y kód, tak jste moˇzná jeˇstˇe nepracovali na nˇeˇcem opravdu sloˇzitém ˇci nˇeˇcem zahrnuj´ıc´ım spolupráci s v´ıce programátory, protoˇze v tom pˇr´ıpadˇe je rozumnˇe ˇcist´ y kód jednou z podm´ınek u ´spˇechu a jednou ze zkuˇsenost´ı, které z takové spolupráce vycházej´ı. Toto je samozˇrejmˇe zˇc´ asti subjektivn´ı n´ azor, ale ˇcist´ ym kódem nic nezkaz´ıte, minimálnˇe nekaz´ıte oˇci sv´ ym cviˇc´ıc´ım. • informace o C stylu pouˇz´ıvaném pro zdrojové kódy Solarisu, vˇcetnˇe skriptu, kter´ y v´ am zdroj´ aky zkontroluje a upozorn´ı na pˇr´ıpadné nedostatky, je moˇzné nalézt na http://mff.devnull.cz/pvu/common/cstyle.html. Pokud budete dodrˇzovat tento styl pˇri psan´ı zkouˇskov´ ych pˇr´ıklad˚ u, uˇsetˇr´ıte mi t´ım práci pˇri vyhodnocov´ an´ı. Obecnˇe je dobré, abyste si zkusili, co je to psát kód podle nˇejakého konkrétn´ıho stylu, a ten pro dan´ y ,,projekt” dodrˇzet. • bohuˇzel ani v´ yˇse uveden´ y skript nen´ı vˇsemocn´ y. Je zaloˇzen´ y na kontrole pomoc´ı regul´ arn´ıch v´ yraz˚ u, takˇze tˇreba ten assembler styl ze slajdu projde bez chyby, protoˇze bez skuteˇcné anal´ yzy kódu nen´ı moˇzné (?) kontrolovat spr´ avné odsazov´ an´ı. Vˇse ostatn´ı je na nˇem, dle cstyle skriptu, korektn´ı.

20

Utility cc, c99∗ , gcc†

pˇrekladaˇc C

CC, g++†

pˇrekladaˇc C++

ld

spojovac´ı program (linker)

ldd

pro zjistˇen´ı závislost´ı dynamického objektu

cxref

∗

kˇr´ıˇzové odkazy ve zdrojov´ ych textech v C

∗

sccs , rcs,cvs

spr´ ava verz´ı zdrojového kódu

make∗

ˇr´ızen´ı pˇrekladu podle závislost´ı

ar

∗

spr´ ava knihoven objektov´ ych modul˚ u

dbx, gdb

†

debuggery

prof, gprof ∗

SUSv3

†

†

profilery

GNU

SUSv3 • standardn´ı pˇr´ıkaz vol´ an´ı kompilátoru a linkeru C je c99 (podle ISO normy pro C z roku 1999) • cb (C program beautifier) nen´ı • pro spr´ avu verz´ı je sccs • debuggery a profilery nejsou

21

Konvence pro jm´ ena soubor˚ u *.c

jména zdrojov´ ych soubor˚ u program˚ uvC

*.cc

jména zdrojov´ ych soubor˚ u program˚ u v C++

*.h

jména hlaviˇckov´ ych soubor˚ u (header˚ u)

*.o

pˇreloˇzené moduly (object files)

a.out

jméno spustitelného souboru (v´ ysledek u ´spˇeˇsné kompilace)

/usr/include

koˇren stromu systémov´ ych header˚ u

/usr/lib/lib*.a

statické knihovny objektov´ ych modul˚ u

/usr/lib/lib*.so

um´ıstˇen´ı dynamick´ ych sd´ılen´ ych knihoven objektov´ ych modul˚ u

statick´ e knihovny – pˇri linkov´ an´ı se kód funkc´ı pouˇzit´ ych z knihovny stane souˇc´ ast´ı v´ ysledného spustitelného programu. Dnes se uˇz moc nepouˇz´ıvá. sd´ılen´ e knihovny – program obsahuje pouze odkaz na knihovnu, pˇri spuˇstˇen´ı programu se potˇrebné knihovny naˇctou do pamˇeti ze soubor˚ u *.so a pˇrilinkuj´ı. • dnes se vˇetˇsinou pouˇz´ıvaj´ı sd´ılené knihovny, protoˇze nezab´ıraj´ı tolik diskového prostoru (knihovna je na disku jednou, nen´ı souˇcást´ı kaˇzdého spustitelného souboru) a snadnˇeji se upgraduj´ı (staˇc´ı instalovat novou verzi knihovny, nen´ı tˇreba pˇrelinkovat programy). Posledn´ı verze Solarisu uˇz napˇr´ıklad v˚ ubec neobsahuje libc.a, d´ıky ˇcemuˇz jiˇz programátor nem˚ uˇze vytvoˇrit statickou bin´ arku, aniˇz by nemˇel dostateˇcné znalosti systému. • nˇekdy se bez statick´ ych knihoven neobejdeme. V nˇekter´ ych situac´ıch nen´ı moˇzné pouˇz´ıt knihovny dynamické, spustitelné soubory jsou takzvané standalone binaries a pouˇzit´ı naleznou napˇr´ıklad pˇri bootován´ı operaˇcn´ıho systému.

22

Princip pˇ rekladu

util.c msg() { puts(); }

systémová knihovna

program a.out

main msg ??

main msg

util.o msg puts ??

linker

main() { msg(); }

objektové moduly main.o

pˇrekladaˇc

zdrojové moduly main.c

msg puts

puts

puts

• u sloˇzitˇejˇs´ıch program˚ u b´ yvá zvykem rozdˇelit zdrojov´ y text programu do nˇekolika modul˚ u, které obsahuj´ı pˇr´ıbuzné funkce a tyto moduly se pak mohou pˇrekl´ adat zvl´ aˇst’ (dokonce kaˇzd´ y modul m˚ uˇze b´ yt v jiném jazyce a pˇrekládán jin´ ym pˇrekladaˇcem). V´ yhodou je jednak urychlen´ı pˇrekladu (pˇrekládaj´ı se vˇzdy jen moduly zmˇenˇené od posledn´ıho pˇrekladu) a jednak flexibilita (nˇekteré moduly se mohou pouˇz´ıvat v r˚ uzn´ ych programech). Pro ˇr´ızen´ı pˇrekladu se obvykle pouˇz´ıv´ a utilita make. • pˇrekladaˇc jednotlivé zdrojové moduly pˇreloˇz´ı do tvaru tzv. objektových modul˚ u, jeˇz obsahuj´ı k´ od programu (vˇcetnˇe volán´ı lokáln´ıch funkc´ı), ale nam´ısto vol´ an´ı extern´ıch funkc´ı obsahuj´ı jen tabulku jejich jmen. • po f´ azi pˇrekladu nastupuje spojovac´ı program (téˇz linker editor nebo loader ), kter´ y zkompletuje v´ ysledn´ y program vˇcetnˇe vyˇreˇsen´ı extern´ıch odkaz˚ u mezi moduly a systémov´ ymi knihovnami resp. mezi moduly navzájem. • pouˇzité statické knihovny jsou zkop´ırovány do spustitelného souboru. Na sd´ılené knihovny jsou ve spustitelném souboru pouze odkazy a linkuje je runtime linker pˇri kaˇzdém spuˇstˇen´ı programu. V´ıce viz dynamick´ y linker na stranˇe 36. • pomoc´ı parametr˚ u linkeru lze urˇcit, zda se budou pouˇz´ıvat statické nebo dynamické knihovny. Zdrojov´ y kód je v obou pˇr´ıpadech stejn´ y. Existuje i mechanismus (dlopen, dlsym. . . ), pomoc´ı kterého se za bˇehu programu vybere sd´ılen´ a knihovna a daj´ı se volat jej´ı funkce. T´ımto zp˚ usobem m˚ uˇzete také zjistit, zda v systému je pˇr´ıtomna pˇr´ısluˇsná funkcionalita a pokud ne, zachovat se podle toho. V´ıce na stranˇe 150. 23

Pˇ reklad jednoho modulu (preprocesor)

/usr/include/stdio.h int puts(char *s);

main.i int puts(char *s); preprocesor

main.c #include <stdio.h> #include ”mydef.h” main() { puts(MSG); }

mydef.h #define MSG ”Ahoj” extern int var a;

extern int var a; main() { puts("Ahoj"); }

• preprocesor prov´ ad´ı expanzi maker, ˇcten´ı vloˇzen´ ych (include) soubor˚ u a vynech´ av´ a koment´ aˇre. • v´ ystup preprocesoru lze z´ıskat pomoc´ı cc -E pˇr´ıpadnˇe pˇr´ımo zavolán´ım cpp, nemus´ı to b´ yt ale vˇzdy totéˇz protoˇze nˇekteré pˇrekladaˇce maj´ı preprocesor integrov´ an v sobˇe. Preprocesor m˚ uˇzete samozˇrejmˇe pouˇz´ıvat i pro jiné projekty, které s pˇrekladem zdrojov´ ych soubor˚ u v jazyce C nemus´ı m´ıt v˚ ubec nic spoleˇcného. • pouˇzit´ı preprocesoru se m˚ uˇze velmi hodit v situaci, kdy potˇrebujete zasáhnout do ciz´ıho k´ odu, plného podm´ıneˇcn´ ych vkládán´ı r˚ uzn´ ych hlaviˇckov´ ych soubor˚ u a r˚ uzn´ ych definic z´ avisl´ ych na dan´ ych podm´ınkách. Pˇri hledán´ı p˚ uvodce chyby v´ am pr´ avˇe m˚ uˇze hodnˇe pomoci samostatného zpracován´ı vstupn´ıho souboru pomoc´ı preprocesuru, kde problém jiˇz vˇetˇsinou rozpoznáte snadno. • cpp (nebo cc -E v´ am dok´ aˇze na standardn´ı chybov´ y v´ ystup zobrazit i cel´ y strom vkl´ adan´ ych soubor˚ u, coˇz opˇet pˇri podm´ıneˇcn´ ych pˇrekladech m˚ uˇze b´ yt velmi uˇziteˇcn´ a vˇec. Staˇc´ı pro to pouˇz´ıt volbu -H a pˇresmˇerovat v´ ystup do /dev/null ˇc´ımˇz dostanete pouze hierarchii vkládan´ ych hlaviˇckov´ ych soubor˚ u.

24

Pˇ reklad jednoho modulu (kompil´ ator) main.s

main.i

.globl main .type main, @function main: pushhl %ebp movl %esp, %ebp pushl $.LC0 call puts addl $4, %esp .L1: leave ret

extern int var a; main() { puts("Ahoj"); }

kompilátor

int puts(char *s);

• obr´ azek v´ yˇse je pˇr´ıklad v´ ystupu pro i386 platformu (32-bit, AT&T syntax). • pˇreklad z C do assembleru • v´ ystup této f´ aze pˇrekladu lze z´ıskat pomoc´ı cc -S.

25

Pˇ reklad jednoho modulu (assembler) main.s .globl main .type main, @function main: pushhl %ebp movl %esp, %ebp pushl $.LC0 call puts addl $4, %esp .L1: leave ret

assembler

main.o 457f 0000 0001 0000 00ec 0034

• opˇet pˇr´ıklad v´ ystupu pro i386 platformu (32-bit). • pˇreklad z assembleru do strojového kódu • objektov´ y modul je v´ ysledkem pˇr´ıkazu cc -c.

26

464c 0000 0003 0000 0000 0000

0101 0000 0001 0000 0000 0000

0001 0000 0000 0000 0000 0028

Kompil´ ator • vol´ an´ı: cc [options ] soubor ... • nejd˚ uleˇzitˇejˇs´ı pˇrep´ınaˇce: -o soubor jméno v´ ysledného souboru -c

pouze pˇreklad (nelinkovat)

-E

pouze preprocesor (nepˇrekládat)

-l

slinkuj s pˇr´ısluˇsnou knihovnou

-Ljm´ eno

pˇridej adresáˇr pro hledán´ı knihoven z -l

-Olevel

nastaven´ı u ´rovnˇe optimalizace

-g

pˇreklad s ladic´ımi informacemi

-Djm´ eno

definuj makro pro preprocesor

-Iadres´ aˇ r

um´ıstˇen´ı #include soubor˚ u

• -l/-L jsou pˇrep´ınaˇce linker editoru, tj. kompilátor pˇr´ısluˇsné informace pˇredá, ale jsou pouˇz´ıv´ any tak ˇcasto, ˇze jsou vloˇzeny i do tohoto slajdu. • kompil´ ator a linker maj´ı mnoho dalˇs´ıch pˇrep´ınaˇc˚ u ovlivˇ nuj´ıc´ıch generovan´ y k´ od, vypisov´ an´ı varovn´ ych hláˇsen´ı nebo variantu jazyka (K&R/ANSI). Je tˇreba nastudovat dokumentaci konkrétn´ıho produktu.

27

Pˇ reddefinovan´ a makra __FILE__, __LINE__, __DATE__, __TIME__, __cplusplus, apod. jsou standardn´ı makra kompilátoru C/C++ unix vˇzdy definováno v Unixu mips, i386, sparc hardwarová architektura linux, sgi, sun, bsd klon operaˇcn´ıho systému _POSIX_SOURCE, _XOPEN_SOURCE pˇreklad podle pˇr´ısluˇsné normy pro pˇreklad podle urˇcité normy by pˇred prvn´ım #include mˇel b´ yt ˇr´ adek s definic´ı n´ asleduj´ıc´ıho makra. Pak naˇctˇete unistd.h. UNIX 98

#define _XOPEN_SOURCE 500

SUSv3

#define _XOPEN_SOURCE 600

POSIX1990

#define _POSIX_SOURCE

• funguje to tak, ˇze pomoc´ı konkrétn´ıch maker definujete co chcete (napˇr. POSIX SOURCE) a podle nastaven´ı jin´ ych maker (napˇr. POSIX VERSION) pak zjist´ıte, co jste dostali. Mus´ıte ale vˇzdy po nastaven´ı maker nainkludovat unistd.h a pouˇz´ıt spr´ avn´ y pˇrekladaˇc. Napˇr´ıklad se pokus´ıme pˇreloˇzit program basic-utils/standards.c , kter´ y vyˇzaduje SUSv3, na systému podporuj´ıc´ım SUSv3 (Solaris 10), ale pˇrekladaˇcem, kter´ y podporuje pouze SUSv2 (SUSv3 pˇrekladaˇc je c99). Pozor, ˇze defaultn´ı chován´ı vaˇseho pˇrekladaˇce m˚ uˇze b´ yt klidnˇe pr´ avˇe to z c89. $ cat standards.c #define _XOPEN_SOURCE 600 /* you must #include at least one header !!! */ #include <stdio.h> int main(void) { return (0); } $ c89 basic-utils/standards.c "/usr/include/sys/feature_tests.h", line 336: #error: "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" cc: acomp failed for standards.c • zdroj maker pro standard tedy m˚ uˇze b´ yt jiˇz na stranˇe 15 zmiˇ novan´ y hlaviˇckov´ y soubor feature tests.h na Solarisu. Bud’ ho najdete pˇr´ımo na nˇekterém

28

z tˇechto systém˚ u nebo pˇres code browser OpenGrok na http://src.opensolaris. org/. • v dokumentaci konkrétn´ıho kompilátoru je moˇzné naj´ıt, která dalˇs´ı makra se pouˇz´ıvaj´ı. Mnoˇzstv´ı maker je definováno také v systémov´ ych hlaviˇckov´ ych souborech. • POSIX.1 v sobˇe zahrnuje ANSI C; tedy C89, ne C99 (o C standardech v´ıce na stranˇe 17). • co se t´ yˇce maker k jednotliv´ ym standard˚ um, velmi dobrá je kapitola 1.5 v [Rochkind]. Také doporuˇcuji C program basic-tools/suvreq.c k této kapitole, kter´ y je moˇzné naj´ıt i na m´ ych stránkách v sekci ukázkov´ ych pˇr´ıklad˚ u. • mal´ y pˇr´ıklad na podm´ınˇen´ y pˇreklad: int main(void) { #ifdef unix printf("yeah\n"); #else printf("grr\n"); #endif return (0); } • pˇr´ıklad na pouˇzit´ı LINE

viz basic-tools/main LINE .c

Link editor (linker) • Vol´ an´ı: ld [options ] soubor ... cc [options ] soubor ... • Nejd˚ uleˇzitˇejˇs´ı pˇrep´ınaˇce: -o soubor

jméno v´ ysledného souboru (default a.out)

-llib

linkuj s knihovnou liblib.so nebo liblib.a

-Lpath

cesta pro knihovny (-llib )

-shared

vytvoˇrit sd´ılenou knihovnu

-non shared

vytvoˇrit statick´ y program

29

• linker je program, kter´ y vezme typicky v´ıce objekt˚ u vygenerovan´ ych pˇrekladaˇcem a vytvoˇr´ı z nich bin´ arn´ı program, knihovnu nebo dalˇs´ı objekt vhodn´ y pro dalˇs´ı f´ azi linkov´ an´ı. • pozor na to, ˇze na r˚ uzn´ ych systémech se nˇekteré pˇrep´ınaˇce mohou liˇsit, napˇr´ıklad ld na Solarisu nezná pˇrep´ınaˇce -shared a -non shared, je nutné pouˇz´ıt jiné. • existuje pˇrep´ınaˇc -R, kter´ y umoˇzn ˇuje specifikovat cestu pro hledán´ı knihoven za bˇehu (runtime). Tato cesta se m˚ uˇze liˇsit od cesty specifikované pˇrep´ınaˇcem -L. • u mal´ ych program˚ u (v jednom souboru) lze provést pˇreklad a linkován´ı jedn´ım pˇr´ıkazem cc. U vˇetˇs´ıch program˚ u skládaj´ıc´ıch se z mnoha zdrojov´ ych soubor˚ u a knihoven se obvykle oddˇeluje pˇreklad a linkován´ı a cel´ y proces je ˇr´ızen utilitou make (strana 31).

ˇ ızen´ı pˇ R´ rekladu a linkov´ an´ı (make) • zdrojov´ e texty main.c #include "util.h" main() { msg(); }

util.h void msg();

util.c #include "util.h" msg() { puts(); }

• z´ avislosti

• soubor Makefile prog : main.o util.o main.c & cc -o prog main.o util.o main.o main.o : main.c util.h % & util.h prog cc -c main.c & % util.o : util.c util.h util.o % cc -c util.c util.c

. • program je moˇzné také pˇreloˇzit a slinkovat jedn´ım volán´ım kompilátoru, nebo definovat postup pˇrekladu a linkován´ı pomoc´ı shellového skriptu. D˚ uvodem pro pouˇzit´ı make je to, ˇze vyhodnocuje závislosti mezi soubory a po zmˇenˇe ˇ y nˇekterého zdrojového souboru pˇrekládá jenom to, co na nˇem závis´ı. Cast´ zp˚ usob pˇrekladu softwaru po aplikován´ı zmˇen zp˚ usobem “make clean; make all” je v situaci, kdy cel´ y pˇreklad trvá minuty (des´ıtky minut, hodiny. . . ), trochu nevhodn´ y – pr´ avˇe proto je d˚ uleˇzité m´ıt dobˇre napsan´ y Makefile. • ˇr´ adek “prog : main.o util.o” definuje, ˇze se má nejprve rekurzivnˇe zajistit existence a aktu´ alnost soubor˚ u main.o a util.o. Pak se zkontroluje, zda 30

soubor (c´ıl) prog existuje a je aktuáln´ı (datum posledn´ı modifikace souboru je mladˇs´ı neˇz main.o a util.o). Pokud ano, nedˇelá se nic. Kdyˇz ne, provede se pˇr´ıkaz na n´ asleduj´ıc´ım ˇr´ adku. • make se spouˇst´ı typicky s parametrem urˇcuj´ıc´ı pˇr´ıˇsluˇsn´ y c´ıl (target); pˇri spuˇstˇen´ı bez parametr˚ u se vezme prvn´ı target. To b´ yvá all, coˇz vˇetˇsinou podle unixové konvence pˇreloˇz´ı vˇse, co se pˇreloˇzit má. Následuje pak tˇreba spuˇstˇen´ı make s parametrem install apod. • make je samozˇrejmˇe univerzáln´ı nástroj, pouˇziteln´ y i jinde neˇz u pˇreklad˚ u zdrojov´ ych k´ od˚ u • pˇr´ıklad: basic-utils/Makefile01 . Pozor na to, ˇze pro nestandardn´ı jméno vstupn´ıho souboru je nutné pouˇz´ıt pˇrep´ınaˇc -f: “make -f Makefile01”.

Syntaxe vstupn´ıho souboru (make) • popis z´ avislost´ı c´ıle:

targets : [files ]

• prov´ adˇené pˇr´ıkazy:

command

• koment´ aˇr:

#comment

• pokraˇcovac´ı ˇr´ adek:

line-begin \ line-continuation

• Pozor na to, ˇ ze ˇ r´ adek s pˇ r´ıkazem zaˇ c´ın´ a tabul´ atorem, nikoliv mezerami. Kaˇzd´ y pˇr´ıkazov´ y ˇr´ adek se provád´ı samostatn´ ym shellem, pokud je potˇreba provést v´ıce ˇr´ adk˚ u pomoc´ı jednoho shellu, mus´ı se vˇsechny aˇz na posledn´ı ukonˇcit backslashem (shell je dostane jako jeden ˇrádek). Viz pˇr´ıklad, ve kterém dva posledn´ı echo pˇr´ıkazy jsou souˇcást´ı jednoho if pˇr´ıkazu, kter´ y je spuˇstˇen samostatn´ ym shellem. Dále si vˇsimnˇete, ˇze pokud máte pˇr´ıkaz na v´ıce ˇr´ adk˚ u, mus´ıte kaˇzd´ y ˇr´ adek ukonˇcit zpˇetn´ ym lom´ıtkem. $ cat basic-utils/Makefile02 all: @echo $$$$

31

@echo $$$$ @if true; then \ echo $$$$; \ echo $$$$; \ fi $ make -f Makefile02 5513 5514 5515 5515 • co se t´ yk´ a pouˇzit´ı zpˇetného lom´ıtka, tak to funguje jako oddˇelovaˇc slov, a make m´ısto nˇej vloˇz´ı mezeru. Pˇr´ıklad: basic-utils/Makefile07 . • zdvojen´ım $ se potlaˇc´ı speci´ aln´ı v´ yznam dolaru (viz následuj´ıc´ı slajd) • znak @ na zaˇc´ atku ˇr´ adku potlaˇc´ı jeho v´ ypis – make jinak standardnˇe vypisuje nejdˇr´ıve to, co bude vykon´ avat. • vyps´ an´ı vˇsech pˇrikaz˚ u které bude make provádˇet bez toho aby je skuteˇcnˇe provedl lze dos´ ahnout pouˇzit´ım pˇrep´ınaˇce -n. • znak - na zaˇc´ atku ˇr´ adku zp˚ usob´ı ignorován´ı nenulové návratové hodnoty; jinak make vˇzdy v takové situaci zahlás´ı chyby a okamˇzitˇe skonˇc´ı. Pˇr´ıklad: basic-utils/Makefile04 . • test1: false echo "OK" test2: -false echo "OK"

32

Makra (make) • definice makra: name = string • pokraˇcov´ an´ı vkl´ ad´ a mezeru • nedefinovan´ a makra jsou prázdná • nez´ aleˇz´ı na poˇrad´ı definic r˚ uzn´ ych maker • definice na pˇr´ıkazové ˇr´ adce: make target name =string • vyvol´ an´ı makra: $name (pouze jednoznakové name ), ${name } nebo $(name ) • systémové promˇenné jsou pˇr´ıstupné jako makra

• kdyˇz je stejné makro definováno v´ıcekrát, plat´ı jeho posledn´ı definice, viz pˇr´ıklad basic-utils/Makefile03 . • makra nen´ı moˇzné definovat rekurzivnˇe, viz basic-utils/Makefile05 : $ cat basic-utils/Makefile05 M=value1 M=$(M) value2 all: echo $(M) $ make -f Makefile05 Variable M is recursive. • ˇcasto se pouˇz´ıvaj´ı r˚ uzné rozˇs´ıˇrené verze make (napˇr. GNU, BSD), které um´ı, podm´ınˇené sekce v Makefile, redefinice promˇenn´ ych, apod. • napsat Makefile kter´ y bude fungovat najednou pro r˚ uzné verze make nemus´ı b´ yt jednoduché, proto existuj´ı projekty jako je napˇr. GNU automake. Pro jednoduch´ y podm´ıneˇcn´ y pˇreklad v závislosti na systému a kde se daj´ı oˇcekávat r˚ uzné verze pˇr´ıkazu make, je moˇzné pouˇz´ıt napˇr´ıklad následuj´ıc´ı kód, kter´ y mi fungoval na vˇsech v nˇem zm´ınˇen´ ych systémech (znak ‘ je zpˇetn´ y apostrof, a ’ je norm´ aln´ı apostrof): CFLAGS=‘x=\‘uname\‘; \ if [ $${x} = FreeBSD ]; then \

33

echo elif [ echo elif [ echo fi‘

’-Wall’; \ $${x} = SunOS ]; then \ ’-v’; \ $${x} = Linux ]; then \ ’-Wall -g’; \

all: @echo "$(CFLAGS)" • v ostatn´ıch situac´ıch je vhodné, pˇr´ıpadnˇe nezbytné pouˇz´ıt programy typu autoconf nebo automake. Nˇekteré make implementace maj´ı pˇr´ımo direktivy pro podm´ınˇené zpracov´ an´ı vstupn´ıho souboru, napˇr´ıklad make na BSD. Pˇr´ıklad: basic-utils/Makefile08.bsd . • pˇrep´ınaˇcem -e m˚ uˇzeme make donutit, aby ignoroval nastaven´ı promˇenn´ ych ve vstupn´ım souboru v pˇr´ıpadˇe, ˇze je definována promˇenná prostˇred´ı stejného jména. Norm´ alnˇe make pˇreb´ırá aktuáln´ı nastaven´ı promˇenn´ ych prostˇred´ı jen v pˇr´ıpadˇe, ˇze dané promˇenné nejsou nastavené ve vstupn´ım souboru. Pˇr´ıklad: basic-utils/Makefile06 . • make je velmi siln´ y n´ astroj, staˇc´ı se pod´ıvat do systémov´ ych Makefile soubor˚ u jakéhokoli unix-like systému (najdˇete si na Wikipedii, co to znamená “unix-like”, pokud to nev´ıte). Typickou spoleˇcnou vlastnost´ı je to, ˇze neexistuje dokumentace, jak je dan´ y makefile framework postaven.

Dynamick´ y linker (loader) • pˇreklad vyˇzaduje vˇsechny potˇrebné dynamické knihovny pro kontrolu dosaˇzitelnosti pouˇzit´ ych symbol˚ u • sestaven´ı kompletn´ıho programu se ale provede aˇ z pˇ ri spuˇ stˇ en´ı. To je u ´kol pro dynamick´ y linker (run-time linker, loader ) • seznam dynamick´ ych knihoven zjist´ı ze sekce .dynamic • systém m´ a nastaveno nˇekolik cest, kde se automaticky tyto knihovny hledaj´ı • v sekci .dynamic je moˇzné dalˇs´ı cesty ke knihovnám pˇridat pomoc´ı tag˚ u RUNPATH/RPATH • nalezené knihovny se pˇripoj´ı do pamˇet’ového procesu pomoc´ı vol´ an´ı mmap() (bude pozdˇeji)

34

• proces spuˇstˇen´ı dynamicky slinkovaného programu prob´ıhá takto: – kernel ve vol´ an´ı exec namapuje program do pamˇeti a zjist´ı, jak´ y dynamick´ y linker se m´ a pouˇz´ıt (viz dále) – kernel namapuje linker do pamˇet’ového prostoru spouˇstˇeného programu a pak linkeru pˇred´ a kontrolu. Linker je program sám o sobˇe – na Solarisu je ho moˇzné norm´ alnˇe spustit (má tedy funkci main) a jako parametr mu d´ at jméno programu. Moˇznost spouˇstˇet dynamick´ y linker z pˇr´ıkazového ˇr´ adku je ale hlavnˇe pro experimentovan´ı s linkerem pˇri jeho v´ yvoji. – linker z hlaviˇcky programu zjist´ı, jaké dynamické knihovny program pouˇz´ıv´ a, namapuje je do pamˇeti a zavolá jejich inicializaˇcn´ı funkce, pokud existuj´ı. Mapuj´ı se vˇsechny nalezené závislosti které nejsou nastavené jako lazy (strana 150), rekurz´ıvnˇe prohledáván´ım do ˇs´ıˇrky. V tomto poˇrad´ı se pak také objekty prohledávaj´ı pˇri hledán´ı jednotliv´ ych symbol˚ u. – linker programu pˇred´ a ˇr´ızen´ı (tj. zavolá funkci main) – proces m˚ uˇze i za bˇehu dále vyuˇz´ıvat dynamick´ y linker pomoc´ı volán´ı dlopen a spol.; k tomu se dostaneme na stranˇe 150 • je potˇreba si uvˇedomit, ˇze dynamick´ y linker zde nepracuje jako samostatn´ y proces pˇrestoˇze m´ a svoji vlastn´ı main funkci, jeho kód se pouˇz´ıvá v rámci pamˇet’ového prostoru procesu; program, linker a knihovny dohromady tvoˇ r´ı jeden proces. • n´ asleduj´ıc´ı pˇ r´ıkazy a pˇ r´ıklady se t´ ykaj´ı Solarisu. Pokud to nebude fungovat na jin´ ych systémech, tak maj´ı ekvivaletn´ı nástroje s podobnou funkcionalitou. – seznam sekc´ı se zjist´ı pomoc´ı elfdump -c (GNU má pˇr´ıkazy objdump a elfread). O programov´ ych sekc´ıch bude v´ıce na stranˇe 139. – to, jak´ y dynamick´ y linker se pouˇzije, kernel zjist´ı ze sekce .interp, viz ”elfdump -i” a “ld -I”. To znamená, ˇze si m˚ uˇzete napsat vlastn´ı linker a pomoc´ı -I pro ld ho pak nastavit jako dynamick´ y linker pro v´ aˇs program. – dynamick´ a sekce se vyp´ıˇse pomoc´ı elfdump -d, dynamické knihovny jsou oznaˇcené tagem NEEDED – z´ avislosti na dynamick´ ych knihovnách je moˇzné pohodlnˇe zjistit pomoc´ı pˇr´ıkazu ldd (Solaris, Linux, BSD), kter´ y zjist´ı konkrétn´ı cesty ke knihovn´ am. Tento pˇr´ıkaz ˇreˇs´ı závislosti rekurz´ıvnˇe a uvid´ıte tedy i nepˇr´ımé z´ avislosti - tj. takové knihovny, které jsou pouˇzité knihovnami, které pˇr´ısluˇsn´ y program pouˇz´ıvá pˇr´ımo. Zjistit co je pˇresnˇe závislé na ˇcem je moˇzné pomoc´ı volby -v. Na OS X je ekvivalentem ldd pˇr´ıkaz otool -L. – jaké knihovny byly pˇri spuˇstˇen´ı nakonec pouˇzity m˚ uˇze b´ yt jiné neˇz co uk´ aˇze pˇr´ıkaz ldd, a to tˇreba d´ıky mechanismu LD PRELOAD. Na Solarisu proto existuje pˇr´ıkaz pldd, kter´ y pomoc´ı ˇc´ısla procesu ukáˇze závislosti konkrétn´ıho procesu. Pˇr´ıklad na LD PRELOAD: pouˇzijte jiˇz zm´ınˇen´ y Makefile01, a pˇreloˇzte basic-utils/preload.c takto: “cc -shared -o libpreload.so preload.c”. Pak spust’te program, kter´ y zachyt´ı systémové vol´ an´ı close: “LD_PRELOAD=./libpreload.so ./a.out”.

35

– vˇetˇsinu zde uveden´ ych informac´ı naleznete v manuálové stránce pro dynamick´ y linker v Solarisu, ld.so.1(1), a v´ıce pak v Linker and Libraries Guide na docs.sun.com. Na FreeBSD se dynamick´ y linker naz´ yvá ld-elf.so.1, v linuxov´ ych distribuc´ıch vˇetˇsinou ld-linux.so.1, na IRIXu rld atd. – dynamick´ y linker se typicky dá konfigurovat pomoc´ı nastaven´ı promˇenn´ ych, napˇr´ıklad si zkuste na Solarisu spustit toto: LD_LIBRARY_PATH=/tmp LD_DEBUG=libs,detail date a pro zjiˇstˇen´ı vˇsech moˇznost´ı jak debugovat dynamick´ y linker pouˇzijte: LD_DEBUG=help date – pˇr´ıklad na to, kdy je potˇreba, aby linker hledal knihovny i jinde neˇz v defaultn´ıch adres´ aˇr´ıch (adresáˇre specifikované promˇennou LD LIBRARY PATH se prohled´ avaj´ı jako prvn´ı): $ cp /lib/libc.so.1 /tmp $ LD_LIBRARY_PATH=/tmp sleep 100 & [1] 104547 $ pldd 104547 104547: sleep 100 /tmp/libc.so.1 /usr/lib/locale/cs_CZ.ISO8859-2/cs_CZ.ISO8859-2.so.3 – Solaris m´ a velmi zaj´ımav´ y pˇr´ıkaz elfedit(1), pomoc´ı kterého m˚ uˇzete editovat metadata ELF objektu, napˇr´ıklad pˇrepsat jméno závislé knihovny, zmˇenit nastaven´ı RUNPATH atd. • Obecnˇe plat´ı, ˇze pouˇz´ıvat LD LIBRARY PATH k ovlivnˇen´ı bˇehu dynamického linkeru pro nˇeco jiného neˇz ladˇen´ı dynamick´ ych knihoven pˇri v´ yvoji nebo pˇresunech knihoven mezi adresáˇri nen´ı dobr´ y nápad. Na internetu lze naj´ıt mnoˇzstv´ı ˇcl´ ank˚ u typu ”why is LD LIBRARY PATH evil ?”apod., napˇr. http: //xahlee.org/UnixResource dir/ /ldpath.html. Tato promˇenn´ a je typicky zneuˇz´ıvaná ve startovac´ıch skriptech program˚ u, aby pˇredsunuly alternativn´ı seznam adresáˇr˚ u kde hledat dynamické knihovny na kter´ ych program z´ avis´ı. To vˇetˇsinou proto, ˇze byl program nesprávnˇe slinkov´ an a dynamick´ y linker by podle informac´ı v ELFu nedokázal jinak knihovny naj´ıt. Typick´ y nechtˇen´ y side effect je ˇze program spust´ı jin´ y program kter´ y pouˇz´ıv´ a knihovnu stejného jména, ale ”d´ıky”tomu, ˇze se promˇenné prostˇred´ı dˇed´ı, tak dynamick´ y linker najde tuto knihovnu jako prvn´ı v aresáˇri specifikovaném pomoc´ı LD LIBRARY PATH. Tato knihovna m˚ uˇze b´ yt ale jiné verze, a pak snadno m˚ uˇze doj´ıt k nˇeˇcemu co se vˇetˇsinou naz´ yvá ”nedefinované chov´ an´ı”(viz pˇr´ıklad u dalˇs´ıho slide o ABI).

36

API versus ABI API – Application Programming Interface • rozhran´ı pouˇzité pouze ve zdrojovém kódu • rozhran´ı zdroj´ aku v˚ uˇci systému, knihovnˇe ˇci vlastn´ımu kódu, tj. napˇr. exit(1), printf("hello\n") nebo my function(1, 2) • . . . aby se stejn´ y zdrojov´ y k´ od mohl pˇreloˇzit na vˇsech systémech podporuj´ıc´ı dané API ABI – Application Binary Interface • low-level rozhran´ı aplikace v˚ uˇci systému, knihovnˇe ˇci jiné ˇcásti sama sebe • . . . aby se objektov´ y modul mohl pouˇz´ıt vˇsude tam, kde je podporov´ ano stejné ABI

• Pˇr´ıkladem API je tˇreba API definované normou POSIX.1. • ABI definuje konvenci vol´ an´ı (to jak program pˇredá parametry funkci a jak od n´ı pˇrevezme n´ avratovou hodnotu), jaká jsou ˇc´ısla systémov´ ych volán´ı, jak se systémové vol´ an´ı provede ˇci formát objektového modulu a pˇrij´ıman´ ych argument˚ u, viz pˇr´ıklad dole. • API knihovny pak definuje mimo jiné mnoˇzinu volán´ı která jsou knihovnou definov´ ana, jejich parametry a typy tˇechto parametr˚ u. • n´ asledn´ a uk´ azka je pˇr´ıklad na to, kdy v´ yvojáˇr zmˇen´ı velikost argument˚ u v bajtech (tj. zmˇen´ı ABI knihovny), a nahrad´ı novou verz´ı tu starou. Vˇsimnˇete si, ˇze dynamick´ y linker toto nezjist´ı; nemá totiˇz jak, ˇr´ıd´ı se podle jména knihovny v dynamické sekci programu, a to se nezmˇenilo. Uvedená zmˇena je sice i zmˇena v API a problém by se odstranil, kdybychom main.c znovu pˇreloˇzili se zmˇenˇen´ ym ˇr´ adkem deklarace funkce add. To je ale ˇcasto problém (pˇrekl´ adejte cel´ y systém jen kv˚ uli tomu), proto je tak d˚ uleˇzité dodrˇzovat zpˇetnou kompatibilitu v ABI u knihoven. V´ ysledek n´ asleduj´ıc´ıho pˇrekladu knihovny, programu a jeho spuˇstˇen´ı je jak bychom oˇcek´ avali (pouˇzit cc ze SunStudio, pro gcc pouˇzijte m´ısto -G volbu -shared; novˇejˇs´ı gcc nav´ıc neznaj´ı -R a je m´ısto toho nutné pouˇz´ıt -Xlinker -R .: $ cat main.c int my_add(int a, int b);

37

int main(void) { printf("%d\n", my_add(1, 2)); return (0); } $ cat add.c int my_add(int a, int b) { return (a + b); } $ cc -G -o libadd.so add.c $ cc -L. -ladd -R. main.c $ ./a.out 3 Nyn´ı ale pˇriˇsla dalˇs´ı verze knihovny se stejn´ ym jménem, a ve funkci my add nastala zmˇena v typu argument˚ u, kde m´ısto 4-bajtového integeru se pouˇzije 64-bitov´ y celoˇc´ıseln´ y typ. Program ale o niˇcem nev´ı, nechá se spustit a vrát´ı chybnou hodnotu: $ cat add2.c int64_t my_add(int64_t a, int64_t b) { return (a + b); } $ cc -G -o libadd.so add2.c $ ./a.out -1077941135 • pˇr´ıklad: lib-abi/abi-main.c (komentáˇr v souboru napov´ı jak pouˇz´ıt ostatn´ı soubory ve stejném adresáˇri) • zde pak pˇrich´ az´ı ke slovu verzován´ı knihoven, tj. je nutné “nˇeco” zmˇenit tak, aby po instalaci nové knihovny neˇslo program spustit bez jeho rekompilace. • bin´ arn´ı nekompatibilita je napˇr´ıklad problém u OpenSSL. Vˇetve 0.9.x a 0.9.y nejsou ABI kompatibiln´ı. Konkrétnˇe verze 0.9.7 a 0.9.8, v roce 2009 stále obˇe pouˇz´ıvané. Verze rozliˇsené p´ısmeny, tj. napˇr´ıklad 0.9.8a a 0.9.8g, jsou ABI kompatibiln´ı. Nˇekteré systémy stále pouˇz´ıvaj´ı pouze 0.9.7 (FreeBSD 6.x, Solaris 10), jiné jen 0.9.8 (Solaris 11 Express), dalˇs´ı integruj´ı obˇe vˇetve (r˚ uzné Linuxové distribuce). Problém je, máte-li napˇr´ıklad program pro Solaris 10 pouˇz´ıvaj´ıc´ı libcrypto.so knihovnu, kter´ y chcete pouˇz´ıvat i na Solaris 11 Express (to je jinak d´ıky zpˇetné binárn´ı kompatibilitˇe striktnˇe dodrˇzované mezi ”major”verzemi Solarisu moˇzné - napˇr. program kter´ y bˇeˇzel na Solarisu 2.6 z roku 1997 m˚ uˇze bˇeˇzet na Solarisu 10 z roku 2009 bez nutnosti rekompilace - to se t´ yk´ a systému a knihoven s n´ım dodávan´ ych). Jediné správné reˇsen´ı je zkompilovat pro nov´ y systém, pˇr´ıpadnˇe manuálnˇe zkop´ırovat potˇrebné verze

38

knihoven, coˇz ale zdaleka nen´ı ideáln´ı – program nebude fungovat s novˇe nainstalovan´ ym systémem, ale nikdo najednou nev´ı, proˇc to funguje na stejném systému vedle, a kdyˇz se to zjist´ı tak je opˇet potˇreba manuáln´ı zásah, a pochybuji o tom, ˇze autor “ˇreˇsen´ı” bude instalovat opravené verze pˇri v´ yskytu bezpeˇcnostn´ıch chyb. Nekompatibilita 0.9.x verz´ı je d˚ uvodem, proˇc je v dynamické sekci knihovny i jej´ı celé ˇc´ıslo (bez p´ısmen, ta jak jiˇz v´ıme nejsou pro ABI kompatibilitu u OpenSSL d˚ uleˇzitá), a d´ıky tomu je pak toto ˇc´ıslo uvedeno i v kaˇzdém programu proti knihovnˇe slinkovanému: $ elfdump -d /usr/sfw/lib/libcrypto.so.0.9.8 | grep SONAME [7] SONAME 0x1 libcrypto.so.0.9.8 $ elfdump -d /usr/bin/ssh [1] NEEDED [3] NEEDED [5] NEEDED [7] NEEDED [9] NEEDED [10] NEEDED

| grep NEEDED 0x3c99 0x3cb1 0x3cc6 0x3d12 0x3cd9 0x3cfe

libsocket.so.1 libnsl.so.1 libz.so.1 libcrypto.so.0.9.8 libgss.so.1 libc.so.1

– pˇr´ıˇcinou zpˇetné nekompatibility OpenSSL verz´ı je to, ˇze z historick´ ych d˚ uvod˚ u jsou nˇekteré pouˇz´ıvané struktury v hlaviˇckov´ ych souborech. Tyto struktury je ale nˇekdy nutné rozˇs´ıˇrit, napˇr´ıklad pˇri v´ yvoji nové funkcionality. T´ım nastane situace, ˇze program pˇreloˇzen´ y s verz´ı 0.9.7 by pˇredal novˇejˇs´ı knihovnˇe “menˇs´ı” strukturu, respektive nová knihovna by pˇristupovala ve staré struktuˇre na poloˇzky, které neexistuj´ı – a tedy by pˇristupovala k pamˇeti, která programu nebyla pˇridˇelena. To m˚ uˇze zp˚ usobit p´ ad programu (pˇr´ıstup na nenamapovanou stránku), m˚ uˇze to fungovat d´ ale (v dané pamˇeti je to, co se tam typicky oˇcekává, napˇr´ıklad nula), nebo se to zaˇcne chovat “podivnˇe” (v pamˇeti bylo nˇeco, co v dané situaci oˇcek´ avané nebylo). Problém v OpenSSL je, ˇze nyn´ı jiˇz nen´ı technicky jednoduché z tˇechto struktur udˇelat intern´ı a navenek pracovat jen s transparentn´ımi referencemi objektov´ ym pˇr´ıstupem, coˇz by umoˇznilo dˇelat libovolné zmˇeny ve strukturách, aniˇz by to program ovlivnilo. – bˇeˇznˇe vidˇené ˇreˇsen´ı zp˚ usobené neznalost´ı vˇeci je vytvoˇrit symbolick´ y link, napˇr´ıklad na Solarisu 11 udˇelat 0.9.7 symlink na existuj´ıc´ı knihovnu ˇ y v´ verze 0.9.8. Cast´ ysledek je pak pád programu a u ´div autora symlinku. Nˇekdy to naopak funguje, protoˇze program náhodou nepouˇz´ıvá pˇr´ısluˇsné struktury, a to je jasn´ ym d˚ ukazem pro aktéra, ˇze ˇreˇsen´ı mus´ı b´ yt správné. M˚ uˇze se ale st´ at, ˇze program struktury nepouˇz´ıvá pˇri konkrétn´ım provedeném testu, ale zaˇcne dˇelat problémy aˇz pˇri ˇzivém nasazen´ı. Tady je jedin´ a rada – pokud si opravdu nejste jisti ˇze v´ıte, co dˇeláte a nejste si jist´ı svoji detailn´ı znalost´ı kódu programu i knihoven, vyhnˇete se tomu. Nebo riskujte, ale jiˇz v´ıte jak to m˚ uˇze skonˇcit. – zd´ anlivˇe jednoduché ˇreˇsen´ı dodávat v´ıce verz´ı OpenSSL s jedn´ım systémem pˇrin´ aˇs´ı zase jiné problémy – obt´ıˇznˇejˇs´ı v´ yvoj systému, obt´ıˇznˇejˇs´ı spr´ avu systému (pˇri v´ yskytu bezpeˇcnostn´ı chyby je ˇcasto nutné patchovat vˇsechny instalované verze), problémy s nepˇr´ım´ ymi závislostmi obsahuj´ıc´ı v´ıce verz´ı dané knihovny apod. – upgrade verze OpenSSL v existuj´ıc´ım systému je také vˇec, které je dobré se vyhnout, respektive toto tˇeˇzko vyˇreˇs´ıte vydán´ım patche pro existuj´ıc´ı systémy – uvaˇzte ˇze z´ akazn´ık pouˇz´ıvá své nebo j´ım koupené programy,

39

které z´ avis´ı na existuj´ıc´ı verzi. A tu byste mu najednou upgradovali na verzi vyˇsˇs´ı, ABI nekompatibiln´ı. – typick´ ym pˇr´ıkladem, kdy se pouˇz´ıvá transparentn´ı typ jako reference, coˇz umoˇzn ˇuje dalˇs´ı rozˇsiˇrován´ı pod n´ı leˇz´ıc´ı struktury bez rizika v´ yˇse uveden´ ych problém˚ u, je typ POSIX vláken. Struktura typu pthread t (strana 194) je intern´ı záleˇzitost´ı knihovny. Typicky je to integer, ale to by program´ atora nemˇelo v˚ ubec zaj´ımat. Samozˇrejmˇe souborov´ y deskriptor ˇci ˇc´ıslo procesu jsou podobné pˇr´ıpady, ale na pˇr´ıkladu vláken je to lépe vidˇet.

Debugger dbx • Vol´ an´ı: dbx [ options ] [ program [ core ] ] • Nejbˇeˇznˇejˇs´ı pˇr´ıkazy: run [arglist ] where print expr set var = expr cont next, step stop condition trace condition command n help [name ] quit

start programu vypiˇs zásobn´ık vypiˇs v´ yraz zmˇen ˇ hodnotu promˇenné pokraˇcován´ı bˇehu programu proved’ ˇrádku (bez/s vnoˇren´ım do funkce) nastaven´ı breakpointu nastaven´ı tracepointu akce na breakpointu (pˇr´ıkazy následuj´ı) nápovˇeda ukonˇcen´ı debuggeru

• z´ akladn´ı ˇr´ adkov´ y symbolick´ y debugger, aby bylo moˇzné ho plnˇe vyuˇz´ıt, mus´ı b´ yt program pˇreloˇzen s ladic´ımi informacemi (cc -g). Ladˇen´ y program se startuje z debuggeru pˇr´ıkazem run, nebo se debugger pˇripoj´ı k jiˇz bˇeˇz´ıc´ımu procesu. Pomoc´ı dbx lze analyzovat i havarovan´ y program, kter´ y vygeneroval soubor core. • je moˇzné ho naj´ıt napˇr. na Solarisu, avˇsak na Linuxu a FreeBSD defaultnˇe nen´ı. • pro debugging se zdrojov´ ymi kódy nestaˇc´ı pouˇz´ıt volbu -g, je zároveˇ n nutné m´ıt i zdroj´ aky a objektové moduly tam, kde byly pˇri pˇrekladu. To je typicky bˇeˇzn´ a situace, protoˇze lad´ıte na stroji, kde zároveˇ n i vyv´ıj´ıte. Pokud tomu tak nen´ı, je nutné si zdroj´ aky a objektové moduly zajistit, pokud k nim vede jin´ a cesta, lze pouˇz´ıt dbx pˇr´ıkaz pathmap. • gdb-kompatibiln´ı m´ od se spust´ı pˇres gdb on. Pokud vás zaj´ımá, jak´ y má

40

dbx ekvivalentn´ı pˇr´ıkaz ke konkrétn´ımu gdb pˇr´ıkazu, pom˚ uˇze vám help FAQ; hned prvn´ı ot´ azka je “A.1 Gdb does <something>; how do I do it in dbx?” • pokud nepouˇzijete pˇrep´ınaˇc -g, bude vám dbx na Solarisu stále platn´ y, protoˇze zobraz´ı argumenty funkc´ı. U BSD systém˚ u a linuxov´ ych distribuc´ı -g pouˇz´ıt mus´ıte, jinak v´ am debuggery moc nepomohou. Kdy je to na Solarisu platné i bez -g je v vidˇet v pˇr´ıkladu debug/dbx.c . Pˇri kompilaci s gcc a pouˇzit´ı gdb neuk´ aˇze pˇr´ıkaz where parametry funkce crash() zat´ımco se Solaris Studio kompilerem a debuggerem dbx se parametry funkce vyp´ıˇs´ı, takˇze je vidˇet hodnota kter´ a se pˇriˇrazovala. • pˇr´ıklad: debug/coredump.c . Po pˇreloˇzen´ı a spuˇstˇen´ı program spadne a zanech´ a core dump. $ cc coredump.c $ ./a.out Segmentation Fault (core dumped) $ dbx ./a.out core Reading a.out core file header read successfully Reading ld.so.1 Reading libc.so.1 program terminated by signal SEGV (no mapping at the fault address) 0x08050a05: bad_memory_access+0x0015: movb %al,0x00000000(%edx) (dbx) where =>[1] bad_memory_access(0x8047ae8, 0x8047a44, ... [2] main(0x1, 0x8047a50, 0x8047a58, 0x8047a0c), at 0x8050a1b Vid´ıme, ve které funkci to spadlo a je moˇzné se vypsat zásobn´ık. Nevid´ıme ale pˇresnˇe ˇr´ adku k´ odu, kde nastal problém. Pro to je nutné pˇreloˇzit program s lad´ıc´ımi symboly, tj. “cc -g coredump.c”. Zájemce o v´ıce informac´ı o debugging pod unixem odkazuji na navazuj´ıc´ı pˇrednáˇsku “Programován´ı v UNIXu II.” (NSWI138). $ cc -g coredump.c $ dbx ./a.out core Reading a.out core file header read successfully Reading ld.so.1 Reading libc.so.1 program terminated by signal SEGV (no mapping at the fault address) Current function is bad_memory_access 8 x[0] = ’\0’; (dbx)

41

GNU debugger gdb • Vol´ an´ı: gdb [ options ] [ program [ core ] ] • Nejbˇeˇznˇejˇs´ı pˇr´ıkazy: run [arglist ] bt print expr set var = expr cont next, step break condition help [name ] quit

start programu vypiˇs zásobn´ık vypiˇs v´ yraz zmˇen ˇ hodnotu promˇenné pokraˇcován´ı bˇehu programu proved’ ˇrádku (bez/s vnoˇren´ım do funkce) nastaven´ı breakpointu nápovˇeda ukonˇcen´ı debuggeru

• GNU obdoba dbx. M´ od kompatibiln´ı s dbx spust´ıte pˇres -dbx. • na r˚ uzn´ ych platform´ ach existuj´ı i debuggery s grafick´ ym rozhran´ım, napˇr. ˇ workshop (Solaris), cvd (IRIX), xxgdb (GNU), ddd (GNU). Casto funguj´ı jako nadstavby nad dbx, gdb. • #include <stdio.h> int main(void) { printf("hello, world\n"); return (0); } $ cc -g main.c $ gdb -q a.out (gdb) break main Breakpoint 1 at 0x8048548: file main.c, line 4. (gdb) run Starting program: /share/home/jp/src/gdb/a.out Breakpoint 1, main () at main.c:4 4 printf("hello, world\n"); (gdb) next hello, world 5 return (0); (gdb) c Continuing. Program exited normally.

42

(gdb) q • debuggery jsou v´ yborn´ ymi pomocn´ıky pokud váˇs program konˇc´ı na chyby typu “segmentation error” – tj. kdyˇz zkus´ıte nekorektnˇe pˇristoupit do pamˇeti, napˇr´ıklad tam kde nem´ ate co dˇelat. Kdyˇz pˇri pˇrekladu pouˇzijete option -g, uk´ aˇze v´ am pak debugger pˇresnˇe ˇc´ıslo ˇrádku, kde nastal problém. Konkrétn´ı pˇr´ıklad (proˇc se vlastnˇe tento program chová jak se chová??? Hint: zkuste pˇreloˇzit na Solarisu pˇrekladaˇcem cc a spustit): $ cat -n main.c 1 int 2 main(void) 3 { 4 char *c = "hey world"; 5 c[0] = ’\0’; 6 return (0); 7 } } $ gcc -g main.c $ ./a.out Bus error (core dumped) $ gdb a.out a.out.core ... Core was generated by ‘a.out’. Program terminated with signal 10, Bus error. ... #0 0x080484e6 in main () at main.c:5 5 c[0] = ’\0’;

43


Standardn´ı hlaviˇ ckov´ e soubory (ANSI C) stdlib.h errno.h stdio.h ctype.h string.h time.h math.h setjmp.h assert.h stdarg.h limits.h signal.h

... ... ... ... ... ... ... ... ... ... ... ...

z´ akladn´ı makra a funkce oˇsetˇren´ı chyb vstup a v´ ystup pr´ ace se znaky pr´ ace s ˇretˇezci pr´ ace s datem a ˇcasem matematické funkce dlouhé skoky ladic´ı funkce pr´ ace s promˇenn´ ym poˇctem parametr˚ u implementaˇcnˇe závislé konstanty oˇsetˇren´ı signál˚ u

44

• hlaviˇckov´ y soubor (header file) je soubor s deklaracemi funkc´ı (forward declaration), promˇenn´ ych a maker. Z pohledu preprocesoru je to obyˇcejn´ y soubor napsan´ y v jazyce C. • tyto hlaviˇ ckov´ e soubory nejsou specifick´ e pro UNIX. Jsou souˇ c´ ast´ı standardu ANSI C, kter´ y jak jiˇ z v´ıme (strana 17), je zahrnut v POSIX.1. Je ale d˚ uleˇ zit´ e si uvˇ edomit, ˇ ze tyto hlaviˇ ckov´ e soubory mus´ı podporovat kaˇ zd´ y syst´ em, kter´ y podporuje ANSI C, at’ jiˇ z podporuje POSIX.1 nebo ne. • pˇr´ısluˇsn´ y hlaviˇckov´ y soubor pro konkrétn´ı funkci najdete v manuálové stránce dané funkce, toto je zaˇc´ atek manuálové stránky na Solarisu pro memcpy: Standard C Library Functions

memory(3C)

NAME memory, memccpy, memchr, memcmp, memcpy, memmove, memory operations

memset

-

SYNOPSIS #include <string.h> ... ... • jednotliv´ a makra obsaˇzen´ a v tˇechto souborech vˇetˇsinou nejsou vysvˇetlena, v´ yznam jednotliv´ ych maker je ale moˇzné si vyhledat v pˇr´ısluˇsn´ ych specifikac´ıch, které jsou on-line. Na nˇekter´ ych systémech (Solaris) maj´ı jednotlivé hlaviˇckové soubory svoji vlastn´ı manuálovou stránku (man stdlib.h). • makro assert je moˇzné z bˇehem kompilace odstranit pomoc´ı makra NDEBUG. Pˇr´ıklad: assert/assert.c . cat assert.c #include int main(void) { assert(1 == 0); return (13); } $ cc assert.c $ ./a.out Assertion failed: 1 == 0, file assert.c, line 6 Abort (core dumped) $ cc -DNDEBUG assert.c $ ./a.out $ echo $? 13

45

Standardn´ı hlaviˇ ckov´ e soubory (2) unistd.h

...

symbolické konstanty, typy a základn´ı funkce

sys/types.h

...

datové typy

fcntl.h

...

ˇr´ıd´ıc´ı operace pro soubory

sys/stat.h

...

informace o souborech

dirent.h

...

procházen´ı adresáˇr˚ u

sys/wait.h

...

ˇcek´ an´ı na synovské procesy

sys/mman.h

...

mapován´ı pamˇeti

curses.h

...

ovl´ adán´ı terminálu

regex.h

...

pr´ ace s regulárn´ımi v´ yrazy

• tyto headery uˇz patˇr´ı do UNIXu. • zaj´ımavé m˚ uˇze b´ yt pod´ıvat se do sys/types.h

46

Standardn´ı hlaviˇ ckov´ e soubory (3) semaphore.h

...

semafory (POSIX)

pthread.h

...

vl´ akna (POSIX threads)

sys/socket.h

...

s´ıt’ová komunikace

arpa/inet.h

...

manipulace se s´ıt’ov´ ymi adresami

sys/ipc.h

...

spoleˇcné deklarace pro System V IPC

sys/shm.h

...

sd´ılená pamˇet’ (System V)

sys/msg.h

...

fronty zpráv (System V)

sys/sem.h

...

semafory (System V)

• dokonˇcen´ı nejd˚ uleˇzitˇejˇs´ıch UNIXov´ ych header˚ u. Existuj´ı samozˇrejmˇe jeˇstˇe dalˇs´ı.

47

Funkce main() • pˇri spuˇstˇen´ı programu je pˇredáno ˇr´ızen´ı funkci main(). • int main (int argc, char *argv []); – argc . . . poˇcet argument˚ u pˇr´ıkazové ˇrádky – argv . . . pole argument˚ u ∗ podle konvence je argv[0] jméno programu (bez cesty) ∗ posledn´ı prvek je argv[argc] == NULL

– n´ avrat z main() nebo volán´ı exit() ukonˇc´ı program – standardn´ı n´ avratové hodnoty EXIT_SUCCESS (0) a EXIT_FAILURE (1) ls -l / argc argv

3

argv[0] argv[1] argv[2] argv[3]

”ls” ”-l” ”/”

• prvn´ı parametr (typu int) udává poˇcet argument˚ u na pˇr´ıkazovém ˇrádku (vˇcetnˇe argumentu 0 – jména programu) a druh´ y parametr (typu char**) je pole ukazatel˚ u na tyto ˇretˇezce. Za posledn´ım ˇretˇezcem je jeˇstˇe ukonˇcovac´ı NULL pointer – pozor na to, ˇze to je nˇeco jiného neˇz prázdn´ y ˇretˇezec. • argv[0] nˇekdy b´ yv´ a d˚ uleˇzit´ ym zdrojem pˇridané informace. Na Solarisu jsou napˇr´ıklad pˇr´ıkazy cp, mv a ln nalinkované na stejn´ y soubor. Hodnota argv[0] pak urˇcuje, jakou funkci vlastnˇe proces má. Jin´ y pˇr´ıklad – pokud má shell prvn´ı znak z argv[0] nastaven na “-”, znamená to, ˇze se má chovat jako login shell (pod´ıvejte se tˇreba do manuálové stránky pro bash na sekci INVOCATION, pokud nev´ıte, co to je login shell). Ve v´ ypisu proces˚ u pak uvid´ıte “-bash”. Toto nen´ı souˇc´ ast UNIX specifikace pro sh, ale pouˇz´ıval to jiˇz Bourne shell na UNIXu V7 (1979) a ostatn´ı shelly to pˇrevzaly. • pˇri spuˇstˇen´ı programu pˇred´ a kód dynamického linkeru ˇr´ızen´ı funkci main, viz strana 36. Staticky slinkovanému programu se ˇr´ızen´ı pˇredá pˇr´ımo. Nepˇr´ıtomnost main v programu zp˚ usob´ı chybu pˇri pˇrekladu na u ´rovni linkeru. Této funkci se pˇred´ a jméno spuˇstˇeného programu, argumenty z pˇr´ıkazové ˇr´ adky a pˇr´ıpadnˇe i promˇenné prostˇred´ı. Ukonˇcen´ı této funkce znamená konec programu a n´ avratov´ a hodnota se pouˇzije jako kód ukonˇcen´ı programu pro OS. Jinou moˇznost´ı ukonˇcen´ı programu je pouˇzit´ı funkce exit nebo _exit, kterou lze pouˇz´ıt kdykoliv, nejen ve funkci main. V C lze pouˇz´ıvat obˇe metody ukonˇcen´ı programu. • pˇred´ an´ı promˇenn´ ych prostˇred´ı tˇret´ım parametrem typu char** nen´ı souˇcást´ı normativn´ı ˇc´ asti C standardu, pouze informativn´ı. Pˇrekladaˇce to ale typicky

48

podporuj´ı. Varianta main s promˇenn´ ymi prostˇred´ı pak vypadá takto: int main(int argc, char *argv [], char *envp []); • n´ avratov´ y typ funkce main by mˇel b´ yt vˇzdy int; pˇrekladaˇc si jinak bude stˇeˇzovat. Z t´ eto hodnoty se ale pouˇ zije pouze nejniˇ zˇ s´ıch 8 bit˚ u, a je to nez´ aporné ˇc´ıslo. Pozor na to, ˇze na rozd´ıl od konvence jazyka C n´ avratov´ a hodnota 0 m´ a v shellu v´ yznam true (´ uspˇech) a nenula v´ yznam false (ne´ uspˇech). Typick´ a konstrukce v shellu vypadá takto: if ! prog; then echo "failure" else echo "success" fi Pˇr´ıklad: main/return-256.c . • nepouˇz´ıvejte proto ve funkci main return (-1) a nikde pak ani exit(-1), z toho vznikne n´ avratov´ a hodnota 255 a kód je matouc´ı. Je v˚ ubec velmi vhodné pouˇz´ıvat pouze 0 a 1, pokud nen´ı zásadn´ı d˚ uvod pro jiné hodnoty, tˇreba ten ˇze jich potˇrebujete v´ıce – m˚ uˇzete se pod´ıvat napˇr´ıklad na manuálovou stránku pro passwd na Solarisu, sekce EXIT STATUS. Pˇr´ıklad: main/return-negative-1.c . • rozd´ıl mezi funkcemi exit a _exit je v tom, ˇze exit pˇred ukonˇcen´ım programu jeˇstˇe vypr´ azdn´ı (pomoc´ı knihovn´ı funkce fflush) a zavˇre streamy a vol´ a funkce zaregistrované pomoc´ı atexit. V závislosti na systému to mohou b´ yt i dalˇs´ı akce. Pro zaj´ımavost, napˇr´ıklad ve FreeBSD je exit systémové volán´ı a exit knihovn´ı funkce, ale na Solarisu jsou obˇe systémov´ ymi volán´ımi. Pˇr´ıklad: exit/exit.c • pˇr´ıklad: main/print-argv.c

49

Promˇ enn´ e prostˇ red´ı • seznam vˇsech promˇenn´ ych prostˇred´ı (environment variables) se pˇred´ av´ a jako promˇenn´ a extern char **environ; • je to pole ukazatel˚ u (ukonˇcené NULL) na ˇretˇezce ve tvaru: promˇ enn´ a =hodnota environ ”SHELL=/bin/bash”

environ[0] environ[1] environ[2] environ[3]

”DISPLAY=:0” ”LOGNAME=beran”

• shell pˇred´ av´ a spuˇstˇenému programu ty promˇenné, které jsou oznaˇceny jako exportované (Bourne-like shellech pˇr´ıkazem export variable ). Po zmˇenˇe obsahu jiˇz jednou exportované promˇenné samozˇrejmˇe nen´ı potˇreba promˇennou znovu exportovat. Pˇr´ıkaz env vám vyp´ıˇse aktuáln´ı promˇenné prostˇred´ı. Abyste pˇridali promˇennou do prostˇred´ı spouˇstˇeného programu staˇc´ı provést pˇriˇrazen´ı na pˇr´ıkazové ˇr´ adce, aniˇz byste museli mˇenit prostˇred´ı vaˇseho shellu: $ date Sun Oct 7 13:13:58 PDT 2007 $ LC_TIME=fr date dimanche 7 octobre 2007 13 h 14 PDT nedivte se, pokud to na vaˇsem systému takto fungovat nebude, v tom pˇr´ıpadˇe nem´ ate instalovan´ y bal´ık s francouzskou lokalizac´ı (coˇz je pravdˇepodobné). • pˇri nahrazen´ı aktu´ aln´ıho obrazu procesu obrazem jin´ ym se pˇredává, pokud se neˇrekne jinak, synovsk´ ym proces˚ um celé pole environ automaticky. Je moˇzné ve vol´ an´ı pˇr´ısluˇsné varianty funkce exec pˇredat pole jiné. • jaké promˇenné prostˇred´ı konkrétn´ı pˇr´ıkaz pouˇz´ıvá (a jak je pouˇz´ıvá) by mˇelo b´ yt v manu´ alové str´ ance. Typicky v sekci nazvané ENVIRONMENT nebo ENVIRONMENT VARIABLES • man napˇr´ıklad pouˇz´ıv´ a PAGER, vipw pak promˇennou EDITOR apod. • pokud je envp tˇret´ım parametrem funkce main, tak je to stejná hodnota co je v ukazateli environ. 50

• pˇr´ıklad: main/print-env.c (vˇcetnˇe pouˇzit´ı env pˇr´ıkazu zp˚ usobem, kter´ y vyˇcist´ı zdˇedˇené promˇenné prostˇred´ı). $ cc print-env.c $ env - XXX=yyy aaa=ABC ./a.out aaa=ABC XXX=yyy

Manipulace s promˇ enn´ ymi prostˇ red´ı • je moˇzné pˇr´ımo mˇenit promˇennou environ, SUSv3 to ale nedoporuˇcuje • char *getenv (const char *name ); – vr´ at´ı hodnotu promˇenné name • int putenv (char *string ); – vloˇz´ı string ve tvaru jm´ eno =hodnota do prostˇred´ı (pˇridá novou nebo modifikuje existuj´ıc´ı promˇennou) • zmˇeny se pˇren´ aˇsej´ı do synovsk´ ych proces˚ u • zmˇeny v prostˇred´ı syna samozˇrejmˇe prostˇred´ı otce neovlivn´ı • existuj´ı i funkce setenv() a unsetenv()

• u putenv se vloˇzen´ y ˇretˇezec stane souˇcást´ı prostˇred´ı (jeho pozdˇejˇs´ı zmˇena tak zmˇen´ı prostˇred´ı) a nesm´ıte proto pouˇz´ıvat retˇezce v automatick´ ych promˇenn´ ych, toto ˇreˇs´ı setenv, kter´ y hodnotu promˇenné zkop´ıruje. • d˚ uleˇzité je zapamatovat si, ˇze synovsk´ y proces zdˇed´ı v okamˇziku svého vzniku od rodiˇce vˇsechny promˇenné prostˇred´ı, ale jakákoliv manipulace s nimi v synovi je lok´ aln´ı a do otce se nepˇrenáˇs´ı. Kaˇzd´ y proces má svou kopii promˇenn´ ych, proto ani n´ asledná zmˇena prostˇred´ı otce nezmˇen´ı promˇenné jiˇz existuj´ıc´ıho potomka. • dalˇs´ı rozd´ıl mezi putenv a setenv je ten, ˇze v setenv mohu definovat, zda existuj´ıc´ı promˇennou chci nebo nechci pˇrepsat. putenv vˇzdy pˇrepisuje. • int main(void) { printf("%s\n", getenv("USER")); return (0);

51

} $ ./a.out jp • jelikoˇz promˇenn´ a environ je obyˇcejné pole ukazatel˚ u na ˇretˇezce, nen´ı nebˇeˇzné narazit na k´ od, kter´ y s t´ımto polem pracuje pˇr´ımo. Pozor vˇsak na to, ˇze v takovém pˇr´ıpadˇe pak jiˇz nesm´ıte pouˇz´ıvat zde uvedené funkce, jinak se m˚ uˇzete dostat do problém˚ u s jejich konkrétn´ı implementac´ı. A hlavnˇe, nov´ y kód takto nepiˇste, protoˇze norma SUSv3 pˇr´ımou práci s t´ımto polem nedoporuˇcuje. • pˇr´ıklad: main/getenv.c • pozor na to, ˇze je rozd´ıl mezi nastaven´ım hodnoty promˇenné na prázdn´ y string a odmaz´ an´ım promˇenné ze seznamu promˇenn´ ych (pomoc´ı unsetenv).

Zpracov´ an´ı argument˚ u programu • obvykl´ y z´ apis v shellu: program -pˇ rep´ ınaˇ ce argumenty • pˇrep´ınaˇce tvaru -x nebo -x hodnota , kde x je jedno p´ısmeno nebo ˇc´ıslice, hodnota je libovoln´ y ˇretˇezec • nˇekolik pˇrep´ınaˇc˚ u lze slouˇcit dohromady: ls -lRa • argument ’--’ nebo prvn´ı argument nezaˇc´ınaj´ıc´ı ’-’ ukonˇcuje pˇrep´ınaˇce, n´ asleduj´ıc´ı argumenty nejsou povaˇzovány za pˇrep´ınaˇce, i kdyˇz zaˇc´ınaj´ı znakem ’-’. • tento tvar argument˚ u poˇzaduje norma a lze je zpracovávat automaticky funkc´ı getopt.

• argumenty lze samozˇrejmˇe zpracovávat vlastn´ı funkc´ı, ale standardn´ı funkce je pohodlnˇejˇs´ı. • argumenty se typicky mohou opakovat, ale to má smysl jen v nˇekter´ ych situac´ıch • poˇrad´ı pˇrep´ınaˇc˚ u m˚ uˇze b´ yt d˚ uleˇzité a je na aplikaci, aby toto specifikovala • UNIX norma definuje pomoc´ı 13 pravidel velmi pˇresnˇe, jak by mˇely vypadat n´ azvy pˇr´ıkaz˚ u a form´ at pˇrep´ınaˇc˚ u. Napˇr´ıklad jméno pˇr´ıkazu by mˇelo b´ yt pouze mal´ ymi p´ısmeny, dlouhé 2–9 znak˚ u, z pˇrenositelné znakové sady. Pˇrep´ınaˇce bez argument˚ u by mˇelo b´ yt moˇzné dát do skupiny za jedn´ım znakem ’–’. Atd. 52

• pouˇz´ıvat ˇc´ıslice jako pˇrep´ınaˇce je zastaralé; je to nˇekde v normˇe SUSv3, i kdyˇz j´ a to v n´ı nenaˇsel. • pozor na Linux a jeho (ponˇekud zvláˇstn´ı a nestandardn´ı) permutován´ı argument˚ u • pˇrep´ınaˇc -W by mˇel b´ yt rezervovan´ y pro vendor options, tj. pro nepˇrenositelná rozˇs´ıˇren´ı

Zpracov´ an´ı pˇ rep´ınaˇ c˚ u: getopt() int getopt(int argc, char *const argv [], const char *optstring ); extern char *optarg ; extern int optind, opterr, optopt ; • funkce dostane parametry z pˇr´ıkazového ˇrádku, pˇri kaˇzdém vol´ an´ı zpracuje a vr´ at´ı dalˇs´ı pˇrep´ınaˇc. Pokud má pˇrep´ınaˇc hodnotu, vr´ at´ı ji v optarg. • kdyˇz jsou vyˇcerp´ any vˇsechny pˇrep´ınaˇce, vrát´ı -1 a v optind je ˇc´ıslo prvn´ıho nezpracovaného argumentu. • moˇzné pˇrep´ınaˇce jsou zadány v optstring, kdyˇz za znakem pˇrep´ınaˇce n´ asleduje ’:’, má pˇrep´ınaˇc povinnou hodnotu. • pˇri chybˇe (nezn´ am´ y pˇrep´ınaˇc, chyb´ı hodnota) vrát´ı ’?’, uloˇz´ı znak pˇrep´ınaˇce do optopt a kdyˇz opterr nebylo nastaveno na nulu, vyp´ıˇse chybové hláˇsen´ı.

• obvykle se nejprve pomoc´ı getopt naˇctou pˇrep´ınaˇce a pak se vlastn´ımi prostˇredky zpracuj´ı ostatn´ı argumenty; ˇcasto jsou to jména soubor˚ u. • je konvenc´ı, ˇze volby v parametru optstring jsou setˇr´ıdˇené.

53

Pˇ r´ıklad pouˇ zit´ı getopt() struct { int a, b; char c[128]; } opts; int opt; char *arg1; while((opt = getopt(argc, argv, "abc:")) != -1) switch(opt) { case ’a’: opts.a = 1; break; case ’b’: opts.b = 1; break; case ’c’: strcpy(opts.c, optarg); break; case ’?’: fprintf(stderr, "usage: %s [-ab] [-c Carg] arg1 arg2 ...\n", basename(argv[0])); break; } arg1 = argv[optind];

• dobr´ ym zvykem je pˇri detekován´ı neznámého pˇrep´ınaˇce nebo ˇspatného zápisu parametr˚ u programu vypsat struˇcnou nápovˇedu, pˇr´ıpadnˇe s odkazem na podrobnˇejˇs´ı dokumentaci, a ukonˇcit program s chybou, tj. s nenulovou n´ avratovou hodnotou. • pˇr´ıklad také ukazuje nebezpeˇcné pouˇzit´ı funkce strcpy • z pouˇzit´ı funkce getopt je vidˇet, ˇze je stavová. Zpracovat dalˇs´ı pole argument˚ u, pˇr´ıpadnˇe zaˇc´ıt opˇet od zaˇcátku, je moˇzné nastaven´ım extern´ı promˇenné optreset na 1. • standardn´ı getopt zachov´ a poˇrad´ı pˇrep´ınaˇc˚ u pˇri zpracován´ı • pˇri pouˇzit´ı nedefinovaného pˇrep´ınaˇce funkce vyp´ıˇse chybu; to lze potlaˇcit nastaven´ım opterr na 0. • pˇr´ıklad: shellov´ y skript getopt/getopts.sh pˇrepsan´ y do jazyka C pomoc´ı getopt funkce, getopt/getopt.c

54

Dlouh´ y tvar pˇ rep´ınaˇ c˚ u • poprvé se objevilo v GNU knihovnˇe libiberty: --jm´ eno nebo --jm´ eno=hodnota • argumenty se permutuj´ı tak, aby pˇrep´ınaˇce byly na zaˇcátku, napˇr. ls * -l je totéˇz jako ls -l *, standardn´ı chován´ı lze doc´ılit nastaven´ım promˇenné POSIXLY_CORRECT. • zpracov´ avaj´ı se funkc´ı getopt long(), která pouˇz´ıvá pole struktur popisuj´ıc´ıch jednotlivé pˇrep´ınaˇce: struct option { const char *name; /* jméno pˇrep´ınaˇce */ int has arg; /* hodnota: ano, ne, volitelnˇ e */ int *flag; /* kdyˇz je NULL, funkce vrac´ı val, jinak vrac´ı 0 a dá val do *flag */ int val; /* n´ avratová hodnota */ };

verze jak se objevila ve FreeBSD (funkce getopt long nen´ı standarizovaná), má n´ asleduj´ıc´ı vlastnosti: • pokud vˇsechny dlouhé pˇrep´ınaˇce maj´ı nastaveny krátkou variantu ve val, je chov´ an´ı getopt long kompatibiln´ı s getopt • je moˇzné zad´ avat argument k dlouhému pˇrep´ınaˇci i s mezerou (napˇr´ıklad --color green) • pokud je nastaven flag, tak getopt long vrac´ı 0, ˇc´ımˇz se tyto dlouhé pˇrep´ınaˇce bez kr´ atké varianty zpracuj´ı v jedné vˇetvi pˇr´ıkazu case • existuje i vol´ an´ı getopt long only, které povoluje i dlouhé pˇrep´ınaˇce uvozené jednou uvozovkou (-option) • funkci getopt long je moˇzné pouˇz´ıvat dvˇemi zp˚ usoby. Prvn´ı zp˚ usob je, ˇze kaˇzd´ y dlouh´ y pˇrep´ınaˇc m´ a koresponduj´ıc´ı krátk´ y – takto lze jednoduˇse pˇridat dlouhé pˇrep´ınaˇce do existuj´ıc´ıho programu a je kompatibiln´ı s getopt. Druh´ y zp˚ usob umoˇzn ˇuje m´ıt samostatné dlouhé pˇrep´ınaˇce. V tom pˇr´ıpadˇe funkce vrac´ı vˇzdy 0 (nekompatibilita s getopt) a promˇenná *flag se nastav´ı na val. • na konkrétn´ım pˇr´ıkladu na následuj´ıc´ı stránce je vidˇet, jak to celé funguje

55

Dlouh´ e pˇ rep´ınaˇ ce (pokraˇ cov´ an´ı) int getopt long(int argc, char * const argv [], const char *optstring, const struct option *longopts, int *longindex ); • optstring obsahuje jednop´ısmenné pˇrep´ınaˇce, longopts obsahuje adresu pole struktur pro dlouhé pˇrep´ınaˇce (posledn´ı z´ aznam pole obsahuje samé nuly) • pokud funkce naraz´ı na dlouh´ y pˇrep´ınaˇc, vrac´ı odpov´ıdaj´ıc´ı val nebo nulu (pokud flag nebyl NULL), jinak je chován´ı shodné s getopt. • do *longindex (kdyˇz nen´ı NULL) dá nav´ıc index nalezeného pˇrep´ınaˇce v longopts.

• toto je upraven´ y pˇr´ıklad z manuálové stránky na FreeBSD: #include <stdio.h> #include #include int ch, fd, daggerset, bflag = 0; static struct option longopts[] = { { "buffy", no_argument, { "fluoride", required_argument, { "daggerset", no_argument, { NULL, 0,

NULL, NULL, &daggerset, NULL,

’b’ }, ’f’ }, 1 }, 0 }};

int main(int argc, char **argv) { while ((ch = getopt_long(argc, argv, "bf:", longopts, NULL)) != -1) switch (ch) { case ’b’: bflag = 1; break; case ’f’: if ((fd = open(optarg, O_RDONLY, 0)) == -1) printf("unable to open %s", optarg); break; case 0: if (daggerset) { printf("Buffy will use her dagger to " "apply fluoride to dracula’s teeth\n"); } break; default: printf("usage: ...\n"); }

56

argc -= optind; argv += optind; return 0; }

Struktura klasick´ eho OS UNIX uˇzivatelský proces pˇreruˇsen´ı návrat

uˇzivatelský reˇzim

rozhran´ı volán´ı jádra reˇzim jádra

subsystém ˇr´ızen´ı soubor˚ u buffery

subsystém ˇr´ızen´ı proces˚ u a pamˇeti

znakové blokové ovladaˇce

IPC plánovaˇc pˇridˇelován´ı pamˇeti

strojovˇe závislá vrstva ovládán´ı hardware hardware

• toto schéma je pˇrevzato z [Bach86], viz literatura. Zd˚ urazˇ nuje dva u ´stˇredn´ı pojmy v modelu systému UNIX – soubory a procesy. V dneˇ sn´ı dobˇ e to vypad´ a velmi odliˇ snˇ e, ale pro n´ as staˇ c´ı tato z´ akladn´ı pˇ redstava. • UNIX rozliˇsuje dva reˇzimy bˇehu procesoru: uˇzivatelský reˇzim a reˇzim j´ adra. V uˇzivatelském reˇzimu nejsou pˇr´ıstupné privilegované instrukce (napˇr. mapov´ an´ı pamˇeti, I/O, maskován´ı pˇreruˇsen´ı). Tyto dva reˇzimy mus´ı b´ yt podporov´ any na hardwarové u ´rovni (procesorem). • procesy bˇeˇz´ı obvykle v uˇzivatelském reˇzimu, do reˇzimu jádra pˇrecház´ı bud’ instrukc´ı synchronn´ıho pˇreruˇsen´ı (trap) pro volán´ı sluˇzby jádra, nebo na z´ akladˇe asynchronn´ıch pˇreruˇsen´ı (hodiny, I/O). Dále se v reˇzimu jádra oˇsetˇruj´ı v´ yjimeˇcné stavy procesoru (v´ ypadek stránky, naruˇsen´ı ochrany pamˇeti, nezn´ am´ a instrukce apod.). Nˇekteré speciáln´ı akce jsou zajiˇst’ovány systémov´ ymi procesy, které bˇeˇz´ı celou dobu v reˇzimu jádra. • klasické UNIXové j´ adro je tvoˇreno monolitick´ ym kódem. P˚ uvodnˇe bylo potˇreba vygenerovat (tj. pˇreloˇzit ze zdrojov´ ych text˚ u a slinkovat) jádro pˇri zmˇenˇe nˇekterého parametru nebo pˇridán´ı ovladaˇce zaˇr´ızen´ı. V novˇejˇs´ıch implementac´ıch je moˇzno nastavovat parametry jádra, nˇekdy i za bˇehu, pomoc´ı systémov´ ych utilit bez nutnosti rekompilace jádra. Modern´ı unixové systémy umoˇzn ˇuj´ı rozˇsiˇrovat k´ od j´ adra za bˇehu pomoc´ı tzv. modul˚ u jádra (loadable kernel modules). Napˇr´ıklad systém FreeBSD 5.4-RELEASE má 392 takov´ ych modul˚ u. 57

• existuj´ı dva zp˚ usoby pr´ ace s perifériemi: bloková (block devices) a znaková zaˇr´ızen´ı (character, raw devices). Data z blokov´ ych zaˇr´ızen´ı (napˇr. disky) proch´ azej´ı pˇres vyrovn´ avac´ı pamˇeti (buffers) po bloc´ıch, znaková zaˇr´ızen´ı (napˇr. termin´ aly) umoˇzn ˇuj´ı pracovat s jednotliv´ ymi bajty a nepouˇz´ıvaj´ı vyrovn´ avac´ı pamˇet’. • j´ adro nen´ı samostatn´ y proces, ale je ˇcást´ı kaˇzdého uˇzivatelského procesu. Kdyˇz j´ adro nˇeco vykon´ av´ a, tak vlastnˇe proces, bˇeˇz´ıc´ı v reˇzimu jádra, nˇeco prov´ ad´ı.

Procesy, vl´ akna, programy • proces je systémov´ y objekt charakterizovan´ y sv´ ym kontextem, identifikovan´ y jednoznaˇcn´ ym ˇc´ıslem (process ID, PID); jin´ ymi slovy ,,k´ od a data v pamˇeti” • vl´ akno (thread) je systémov´ y objekt, kter´ y existuje uvnitˇr procesu a je charakterizován sv´ ym stavem. Vˇsechna vlákna jednoho procesu sd´ıl´ı stejn´ y pamˇet’ov´ y prostor kromˇe registr˚ u procesoru a z´ asobn´ıku; ,,linie v´ ypoˇctu”, ,,to, co bˇeˇz´ı” • program ... soubor pˇresnˇe definovaného formátu obsahuj´ıc´ı instrukce, data a sluˇzebn´ı informace nutné ke spuˇstˇen´ı; ,,spustiteln´ y soubor na disku” ◦ pamˇ et’ se pˇridˇeluje proces˚ um. ◦ procesory se pˇridˇeluj´ı vl´ akn˚ um. ◦ vl´ akna jednoho procesu mohou bˇeˇzet na r˚ uzn´ ych procesorech.

• kontext je pamˇet’ov´ y prostor procesu, obsah registr˚ u a datové struktury j´ adra t´ ykaj´ıc´ı se daného procesu • jinak ˇreˇceno – kontext procesu je jeho stav. Kdyˇz systém vykonává proces, ˇr´ık´ a se, ˇze bˇeˇz´ı v kontextu procesu. Jádro (klasické) obsluhuje pˇreruˇsen´ı v kontextu pˇreruˇseného procesu. • vl´ akna se dostala do UNIXu aˇz pozdˇeji, p˚ uvodnˇe v nˇem existovaly pouze procesy, které mˇely z dneˇsn´ıho pohledu pouze jedno vlákno. Moˇznost pouˇz´ıt v procesu v´ıce vl´ aken byla zavedena, protoˇze se ukázalo, ˇze je vhodné m´ıt v´ıce paraleln´ıch lini´ı v´ ypoˇctu nad sd´ılen´ ymi daty. • pamˇet’ové prostory proces˚ u jsou navzájem izolované, ale procesy spolu mohou komunikovat. Pozdˇeji se dozv´ıme, ˇze mohou i ˇcásteˇcnˇe sd´ılet pamˇet’. • procesy jsou entity na u ´rovni jádra, ale vlákna mohou b´ yt ˇcásteˇcnˇe nebo zcela implementov´ ana knihovn´ımi funkcemi. V pˇr´ıpadˇe implementace pomoc´ı

58

knihovn´ıch fuknc´ı to znamená, ˇze vlákna nemus´ı jádro v˚ ubec podporovat. S vl´ akny je spojena menˇs´ı reˇzie neˇz s procesy. • systémov´ y proces, kter´ y bˇeˇz´ı na pozad´ı obvykle po celou dobu bˇehu systému a zajiˇst’uje nˇekteré systémové sluˇzby (inetd, cron, sendmail. . . ) se naz´ yvá démon (angl. daemon). Systém BSD tedy nemá ve znaku ˇcerta, ale démona.

J´ adro, reˇ zimy, pˇ reruˇ sen´ı (klasick´ y UNIX) • procesy typicky bˇeˇz´ı v uˇzivatelském reˇzimu • systémové vol´ an´ı zp˚ usob´ı pˇrepnut´ı do reˇzimu jádra • proces m´ a pro kaˇzd´ y reˇzim samostatn´ y zásobn´ık • j´ adro je ˇc´ ast´ı kaˇzdého uˇzivatelského procesu, nen´ı to samostn´ y proces (procesy) • pˇrepnut´ı na jin´ y proces se naz´ yvá pˇrepnut´ı kontextu • obsluha pˇreruˇsen´ı se provád´ı v kontextu pˇreruˇseného procesu • klasické j´ adro je nepreemptivn´ı

• j´ adro nen´ı oddˇ elen´ a mnoˇ zina proces˚ u, bˇ eˇ z´ıc´ıch paralelnˇ e s uˇ zivatelsk´ ymi procesy, ale je ˇ c´ ast´ı kaˇ zd´ eho uˇ zivatelsk´ eho procesu. • pˇrechod mezi uˇzivatelsk´ ym reˇzimem a reˇzimem jádra nen´ı pˇrepnut´ı kontextu – proces bˇeˇz´ı poˇr´ ad v tom samém • pˇreruˇsen´ y proces nemusel pˇreruˇsen´ı v˚ ubec zp˚ usobit • v reˇzimu j´ adra m˚ uˇze proces pˇristupovat i k adresám jádra, která z uˇzivatelského reˇzimu pˇr´ıstupn´ a nejsou; taktéˇz m˚ uˇze pˇristupovat k instrukc´ım (napˇr. instrukce manipuluj´ıc´ı se stavov´ ym registrem), jejichˇz vykonán´ı v uˇzivatelském reˇzimu vede k chybˇe • pˇreruˇsovac´ı rutina se nem˚ uˇze zablokovat, protoˇze t´ım by zablokovala proces; proces se totiˇz m˚ uˇze zablokovat jen ze své vlastn´ı v˚ ule. Modern´ı unixy dnes pouˇz´ıvaj´ı interrupt vl´ akna, v jejichˇz kontextu se mohou drivery zablokovat. • to, ˇze klasické unixové j´ adro je nepreemptivn´ı znamená, ˇze jeden proces nem˚ uˇ ze zablokovat jin´ y proces

59

• pˇri obsluze pˇreruˇsen´ı se m˚ uˇze stát, ˇze nastane dalˇs´ı pˇreruˇsen´ı. Pokud je jeho priorita vˇetˇs´ı, je procesorem pˇrijmuto. Posloupnost pˇrijmut´ ych pˇreruˇsen´ı je uchov´ ana v z´ asobn´ıku kontextových vrstev. • u modern´ıch kernel˚ u je situace ˇ casto velmi rozd´ıln´ a – obsluha pˇ reruˇ sen´ı, preeptivnost kernelu atd.; k nˇ ekter´ ym vˇ ecem se moˇ zn´ a dostaneme pozdˇ eji bˇ ehem semestru

Vol´ an´ı sluˇ zeb a komunikace mezi procesy • UNIX proces

proces

proces

rozhran´ı volán´ı jádra jádro • distribuovan´ y OS uˇzivatelský proces

uˇzivatelský proces

server

server

server

jádro

jádro

jádro

jádro

jádro

• pokud unixov´ y proces vyˇzaduje proveden´ı systémové sluˇzby, pomoc´ı systémového vol´ an´ı pˇred´ a ˇr´ızen´ı jádru. Jádro je kus kódu sd´ılen´ y vˇsemi procesy (ovˇsem pˇr´ıstupn´ y jen pro ty, které jsou právˇe v reˇzimu jádra). Jádro tedy nen´ı samostatn´ y privilegovan´ y proces, ale vˇzdy bˇeˇz´ı v rámci nˇekterého procesu (toho, kter´ y poˇz´ adal j´ adro o sluˇzbu, nebo toho, kter´ y bˇeˇzel v okamˇziku pˇr´ıchodu pˇreruˇsen´ı). • komunikace mezi procesy v UNIXu je ˇreˇsena pomoc´ı systémov´ ych volán´ı, je tedy zprostˇredkovan´ a j´ adrem. • aby to nebylo tak jednoduché, mohou existovat systémové procesy (oznaˇcované jako kernel threads), které bˇeˇz´ı celou dobu v reˇzimu jádra. Naprostá vˇetˇsina systémov´ ych proces˚ u vˇsak bˇeˇz´ı v uˇzivatelském reˇzimu a liˇs´ı se jen t´ım, ˇze maj´ı vˇetˇs´ı pˇr´ıstupov´ a práva. Plánovaˇc proces˚ u pˇrep´ıná mezi procesy a t´ım umoˇzn ˇuje bˇeh v´ıce proces˚ u souˇcasnˇe i na jednom procesoru. Na multiprocesorov´ ych poˇc´ıtaˇc´ıch pak funguje skuteˇcn´ y paralelismus proces˚ u a vláken (dokonce se proces m˚ uˇze pˇri pˇreplánován´ı dostat i na jin´ y procesor). • v distribuovaném operaˇcn´ım systému má jádro obvykle formu mikrojádra, tj. zajiˇst’uje pouze nejz´ akladnˇejˇs´ı sluˇzby ˇr´ızen´ı procesoru, pˇridˇelován´ı pamˇeti 60

a komunikace mezi procesy. Vyˇsˇs´ı systémové sluˇzby, které jsou v UNIXu souˇc´ ast´ı j´ adra (napˇr. pˇr´ıstup k systému soubor˚ u) jsou realizovány speciáln´ımi procesy (servery) bˇeˇz´ıc´ımi v uˇzivatelském reˇzimu procesoru. Jádro pˇredá poˇzadavek uˇzivatelského procesu pˇr´ısluˇsnému serveru, kter´ y m˚ uˇze bˇeˇzet i na jiném uzlu s´ıtˇe. • dostupn´ ych mikrokernel˚ u je v dneˇsn´ı dobˇe mnoho. M˚ uˇzete zkusit napˇr´ıklad Minix (unix-like v´ yukov´ y systém), pˇr´ıpadnˇe systém HURD, kter´ y bˇeˇz´ı nad mikroj´ adrem Mach.

Syst´ emov´ a vol´ an´ı, funkce • v UNIXu se rozliˇsuj´ı syst´ emov´ a vol´ an´ı a knihovn´ı funkce. Toto rozliˇsen´ı dodrˇzuj´ı i manuálové stránky: sekce 2 obsahuje systémov´ a vol´ an´ı (syscalls), sekce 3 knihovn´ı funkce (library functions). – knihovn´ı funkce se vykonávaj´ı v uˇzivatelském reˇzimu, stejnˇe jako ostatn´ı k´ od programu. – systémov´ a vol´ an´ı maj´ı také tvar volán´ı funkce. Pˇr´ısluˇsná funkce ale pouze zpracuje argumenty volán´ı a pˇredá ˇr´ızen´ı j´ adru pomoc´ı instrukce synchronn´ıho pˇreruˇsen´ı. Po návratu z j´ adra funkce uprav´ı v´ ysledek a pˇredá ho volaj´ıc´ımu. • standardy tyto kategorie nerozliˇsuj´ı – z hlediska programátora je jedno, zda urˇcitou funkci provede jádro nebo knihovna.

• zjednoduˇsenˇe lze ˇr´ıci, ˇze systémové volán´ı je funkce, která jen uprav´ı své argumenty do vhodné podoby, pˇrepne reˇzim procesoru a skuteˇcnou práci nech´ a na j´ adru. Nakonec zase uprav´ı v´ ysledek. Knihovn´ı funkce m˚ uˇ ze a nemus´ı volat j´ adro, ale vˇ zdy sama dˇ el´ a nˇ ejakou netrivi´ aln´ı ˇ cinnost v uˇ zivatelsk´ em reˇ zimu. • v assembleru je moˇzné zavolat volán´ı jádra pˇr´ımo • API j´ adra je definované na u ´rovni volán´ı funkc´ı standardn´ı knihovny, nikoliv na u ´rovni pˇreruˇsen´ı a datov´ ych struktur pouˇz´ıvan´ ych tˇemito funkcemi pro pˇred´ an´ı ˇr´ızen´ı j´ adru. Mechanismus pˇrepnut´ı mezi uˇzivatelsk´ ym reˇzimem a reˇzimem j´ adra se totiˇz m˚ uˇze liˇsit nejen v závislosti na hardwarové platformˇe, ale i mezi r˚ uzn´ ymi verzemi systému na stejném hardwaru.

61

N´ avratov´ e hodnoty syst´ emov´ ych vol´ an´ı • celoˇc´ıseln´ a n´ avratov´ a hodnota (int, pid t, off t, apod.) – >= 0 . . . operace u ´spˇeˇsnˇe provedena – == -1 . . . chyba • n´ avratov´ a hodnota typu ukazatel – != NULL . . . operace u ´spˇeˇsnˇe provedena – == NULL . . . chyba • po ne´ uspˇeˇsném systémovém volán´ı je kód chyby v globáln´ı promˇenné extern int errno; • u ´spˇeˇsné vol´ an´ı nemˇen´ı hodnotu v errno! Je tedy tˇreba nejprve otestovat n´ avratovou hodnotu a pak teprve errno. • chybové hl´ aˇsen´ı podle hodnoty v errno vyp´ıˇse funkce void perror(const char *s ); • textov´ y popis chyby s dan´ ym ˇc´ıslem vrát´ı funkce char *strerror(int errnum );

• v Solarisu je hodnota errno ve skuteˇcnosti knihovnou libc definovaná jako dereferencovan´ y pointer na integer (specifick´ y pro dan´ y userland thread) a hodnota se nastavuje ihned po v´ ystupu z instrukce pro systémové volán´ı. Napˇr. na i386 architektuˇre je hodnota errno po návratu z kernelu (po dokonˇcen´ı instrukce sysenter) uloˇzena v registru eax (pˇred volán´ım v n´ı bylo ˇc´ıslo syscallu). Je to tedy knihovna libc kdo je zodpovˇedn´ y za to, ˇze program uvid´ı spr´ avnou hodnotu errno. • funkce pro pr´ aci s vl´ akny pthread * nenastavuj´ı errno, ale vrac´ı bud’ nulu (´ uspˇech) nebo pˇr´ımo k´ od chyby. • pro nˇekter´ a vol´ an´ı m˚ uˇze m´ıt smysl i návratová hodnota -1. Pak je tˇreba nejprve nastavit errno = 0 a po návratu zkontrolovat, zda se errno zmˇenilo. Napˇr. funkce strtol vrac´ı pˇri chybˇe 0, coˇz je platná hodnota i pro správn´ y v´ ysledek (a −1 je samozˇrejmˇe platn´ y v´ ysledek také). • je tedy vˇzdy nutné si pˇreˇc´ıst manuálovou stránku pro pˇr´ıˇsluˇsné volán´ı nebo knihovn´ı funkci • pozn.: u ´spˇeˇsnost funkc´ı ze stdio.h je tˇreba testovat pomoc´ı int ferror(FILE *stream ), protoˇze jinak nelze rozliˇsit mezi chybou a koncem streamu. Vzhledem k tomu, ˇze tyto funkce nepouˇz´ıváme (kromˇe printf a fprintf na stdout, resp. stderr), nemˇeli byste ji potˇrebovat.

62

Skupina funkc´ı z err(3) • pomocné funkce pro v´ ypis chybov´ ych hláˇsen´ı a pˇr´ıpadné ukonˇcen´ı programu • m´ısto perror() a exit() vám staˇc´ı jedna funkce • void err(int status, const char *fmt, ...); – vyp´ıˇse jméno programu, formátovan´ y ˇretˇezec, a chybu podle aktu´ aln´ı hodnoty errno – ukonˇc´ı program s n´ avratovou hodnotou ze status • void warn(const char *fmt, ...); – stejné jako err(), ale program neukonˇc´ı • existuj´ı dalˇs´ı podobné funkce, viz manuálová stránka • funkce poch´ azej´ı ze 4.4BSD

• vˇetˇs´ı programy podobné funkce ˇcasto nepouˇz´ıvaj´ı, napˇr´ıklad proto, ˇze stejnˇe potˇrebuj´ı provést r˚ uzné ukonˇcovac´ı práce pˇred skonˇcen´ım programu, takˇze maj´ı podobné funkce vlastn´ı. Pro jiné programy jsou ale tyto funkce ideáln´ı, protoˇze maj´ı rozumn´ y v´ ystup a ˇsetˇr´ı ˇrádky vaˇseho kódu. • tyto funkce nemus´ı b´ yt vˇsude, napˇr´ıklad nejsou v libc.so pro Solaris 10 (ale jsou v Solarisu 11). Jsou na BSD systémech a v linuxov´ ych distribuc´ıch. Tyto funkce nejsou souˇc´ ast´ı SUS, takˇze ani na certifikovan´ ych UNIX systémech se ˇ sen´ım je kontrolovat jejich existenci nelze spolehnout na jejich pˇr´ıtomnost. Reˇ v pˇredkompilaˇcn´ım skriptu a pˇr´ıpadnˇe m´ıt jejich verzi souˇcást´ı zdrojov´ ych k´ od˚ u programu pro pˇr´ıpad ˇze nebudou na c´ılovém systému nalezeny. • pˇr´ıklad (viz také err/err.c ): #include <errno.h> #include <err.h> int main(void) { errno = 13; err(3, "ggr %s", "GRR"); printf("after err()\n"); return (0); }

63

$ ./a.out a.out: ggr GRR: Permission denied $ echo $? 3

Obsah • u ´vod, v´ yvoj UNIXu a C, programátorské nástroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇ r´ıstupov´ a pr´ ava, perifern´ı zaˇ r´ızen´ı, syst´ em soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vláken • ??? - bude definov´ ano pozdˇeji, podle toho kolik zbyde ˇcasu

64

Uˇ zivatel´ e a skupiny beran:x:1205:106:Martin Beran:/home/beran:/bin/bash v´ yznam jednotliv´ ych pol´ı: uˇzivatelské jméno, zahaˇsované heslo (dnes uˇz v /etc/shadow), ˇc´ıslo uˇzivatele (UID); superuˇzivatel (root) m´ a UID 0, ˇc´ıslo primárn´ı skupiny (GID), plné jméno, domovsk´ y adres´ aˇr, login-shell sisal:*:106:forst,beran v´ yznam jednotliv´ ych pol´ı: jméno skupiny, heslo pro pˇrepnut´ı do skupiny, ˇc´ıslo skupiny (GID), seznam ˇclen˚ u skupiny

• informace o uˇzivatel´ıch v souborech /etc/passwd, a /etc/group jsou zpracov´ av´ any r˚ uzn´ ymi systémov´ ymi programy, napˇr. login (pˇrihláˇsen´ı do systému na z´ akladˇe uˇzivatelského jména a hesla) nebo su (zmˇena identity). J´ adro o tˇ echto souborech nic nev´ı, pouˇ z´ıv´ a pouze numerickou identifikaci uˇ zivatele a skupiny. • dnes jiˇz hesla nejsou z bezpeˇcnostn´ıch d˚ uvod˚ u pˇr´ımo v /etc/passwd, ale napˇr´ıklad v /etc/shadow, kter´ y bˇeˇznému uˇzivateli pˇr´ıstupn´ y nen´ı, pouze uˇzivatel root m´ a pr´ avo pro ˇcten´ı a zápis. Tedy pouze privilegované programy jako login nebo sshd mohou z tohoto souboru ˇc´ıst nebo zapisovat (program passwd bˇeˇz´ı pod uˇzivatelem root d´ıky setuid bitu nastaveném na souboru programu, viz poznámky na stranˇe 75). Takto jsou hesla separovan´ a od veˇrejnˇe pˇr´ıstupn´ ych informac´ı, nav´ıc soubor kter´ y hesla obsahuje, je ukl´ ad´ a v zahaˇsované/zaˇsifrované formˇe, takˇze nejsou pˇr´ımo ˇcitelná. Na BSD systémech (napˇr. FreeBSD, Mac OS X) se m´ısto /etc/shadow pouˇz´ıvá soubor /etc/master.passwd. • Soubor /etc/shadow je podobnˇe strukturovan´ y jako /etc/passwd. Jeden z´ aznam obsahuje vˇetˇsinou následuj´ıc´ı poloˇzky (Solaris): uˇzivatelské jméno, zahaˇsované heslo (spolu s indikátorem ˇze dan´ yu ´ˇcet je zablokovan´ y), posledn´ı modifikace hesla, minimum dn´ı poˇzadovan´ ych mezi zmˇenou hesla, maximum dn´ı po které je heslo platné, poˇcet dn´ı po kter´ ych je uˇzivatel varován o expiraci hesla, poˇcet povolen´ ych dn´ı neaktivity uˇzivatele, absolutn´ı ˇcas expirace uˇzivatele, poˇcet ne´ uspˇeˇsy ćh pokus˚ u o nalogován´ı tohoto uˇzivatele. • Hesla v /etc/shadow jsou uloˇzena takov´ ym zp˚ usobem, aby pokud se povede nˇekomu soubor z´ıskat, mˇel zt´ıˇzenou práci pˇri odhadován´ı hesel. P˚ uvodn´ı 65

(cleartext) heslo se proˇzene jednosmˇernou kryptografickou funkc´ı (která je nav´ıc parametrizovateln´ a, ˇc´ımˇz se v´ ypoˇcetn´ı a prostorová sloˇzitost pro u ´tok hrubou silou jeˇstˇe zv´ yˇs´ı) a uloˇz´ı se do /etc/shadow v této formˇe. Ovˇeˇrován´ı hesla pak funguje tak ˇze, se na cleartext heslo aplikuje daná funkce s dan´ ymi parametry a v´ ysledek se porovná s polem hesla v /etc/shadow. Pokud jsou stejné, probˇehla autentizace u ´spˇeˇsnˇe. P˚ uvodnˇe navrˇzená funkce pˇrestala s rozvojem procesor˚ u staˇcit, takˇze se dnes pouˇz´ıvaj´ı funkce MD5, SHA1, Blowfish a dalˇs´ı. Poloˇzka hesla v /etc/shadow je pak vnitˇrnˇe strukturovaná pomoc´ı speci´ aln´ıch znak˚ u, takˇze programy ovˇeˇruj´ıc´ı heslo v´ı, jakou funkci a s jak´ ymi parametry pouˇz´ıt. Vˇetˇsina systém˚ u umoˇzn ˇuje globáln´ı konfiguraci pouˇzit´ ych funkc´ı a jejich parametr˚ u. • existuj´ı i jiné systémy, které (nejen) pro autentizaci /etc/passwd nemus´ı v˚ ubec pouˇz´ıvat, napˇr´ıklad NIS (Network Information Service) nebo LDAP (Lightweight Directory Access Protocol). • skupina uˇzivatele uveden´ a v /etc/passwd se naz´ yvá prim´ arn´ı. Tuto skupinovou identifikaci dostanou napˇr. soubory vytvoˇrené procesy uˇzivatele. Dalˇs´ı skupiny, ve kter´ ych je uˇzivatel uveden v souboru /etc/group, jsou doplˇ nkové (supplementary) a rozˇsiˇruj´ı pˇr´ıstupová práva uˇzivatele: skupinov´ y pˇr´ıstup je povolen ke vˇsem objekt˚ um, jejichˇz skupinov´ y vlastn´ık je roven bud’ primárn´ı, nebo jedné z doplˇ nkov´ ych skupin. • p˚ uvodnˇe mˇel v UNIXu kaˇzd´ y uˇzivatel vˇzdy aktivn´ı pouze jednu skupinovou identitu. Po nalogov´ an´ı byl ve své primárn´ı skupinˇe, pro z´ıskán´ı práv jiné skupiny bylo tˇreba se do n´ı pˇrepnout pˇr´ıkazem newgrp (skupinová obdoba su, ˇr´ıd´ı se obsahem souboru /etc/group), kter´ y spustil nov´ y shell. • v novˇejˇs´ıch UNIXech nen´ı tˇreba pro pˇr´ıstup k soubor˚ um mˇenit primárn´ı skupinovou identitu procesu, pokud uˇzivatel patˇr´ı do potˇrebné skupiny. Zmˇena identity je nutn´ a, pouze kdyˇz chceme vytváˇret soubory s jinou skupinovou identitou, neˇz je prim´ arn´ı skupina uˇzivatele. Lokálnˇe pro urˇcit´ y adresáˇr toho lze dos´ ahnout nastaven´ım skupinového vlastn´ıka adresáˇre na poˇzadovanou skupinu a nastaven´ım bitu SGID v pˇr´ıstupov´ ych právech adresáˇre – to plat´ı pro systémy zaloˇzené na System V. U BSD staˇc´ı zmˇenit poˇzadovanou skupinu u adres´ aˇre. Pˇr´ıklad vytvoˇren´ı takového adresáˇre na Solarisu (pˇr´ıkaz chown mus´ı b´ yt proveden pod uˇzivatelem root): # mkdir mydir # chown :lidi mydir # ls -ald mydir drwxr-xr-x 2 root # cd mydir/ mydir # touch foo mydir # ls -ald foo -rw-r--r-1 root mydir # chmod g+s . mydir # ls -ald . drwxr-sr-x 2 root mydir # touch bar mydir # ls -ald bar -rw-r--r-1 root mydir #

lidi

4 Nov

2 20:01 mydir

root

0 Nov

2 20:01 foo

lidi

4 Nov

2 20:01 .

lidi

0 Nov

2 20:01 bar

66

• druh´ a poloˇzka v ˇr´ adc´ıch /etc/group obsahuje zakódované skupinové heslo pouˇz´ıvané pˇr´ıkazem newgrp, to se jiˇz dnes nepouˇz´ıvá. Napˇr´ıklad na FreeBSD je pˇr´ıkaz newgrp pˇr´ıstupn´ y uˇz jen superuˇzivateli (kv˚ uli volán´ı setgroups).

Name service switch • dneˇsn´ı systémy nejsou omezeny na pouˇz´ıván´ı /etc/passwd a /etc/groups • systém pouˇz´ıv´ a datab´ aze (passwd, groups, protocols, . . . ) • data datab´ az´ı poch´ azej´ı ze zdroj˚ u (soubory, DNS, NIS, LDAP, ...) • soubor nsswitch.conf definuje jaké databáze pouˇz´ıvaj´ı jaké zdroje • knihovn´ı funkce toto samozˇrejmˇe mus´ı explicitnˇe podporovat • je moˇzné nˇekteré zdroje kombinovat, napˇr´ıklad uˇzivatel se nejdˇr´ıve m˚ uˇze hledat v /etc/passwd a poté v NISu • poprvé se objevilo v Solarisu, poté pˇrevzato dalˇs´ımi systémy

• systémy maj´ı typicky manu´ alovou stránku nsswitch.conf(4), kde lze nalézt podrobnosti v z´ avislosti na konkrétn´ım operaˇcn´ım systému, vˇcetnˇe API, pomoc´ı kterého se pracuje s jednotliv´ ymi databázemi. Napˇr´ıklad, s databáz´ı passwd pracuj´ı standardn´ı volán´ı getpwnam(3), getusernam(3) a dalˇs´ı - nen´ı proto potˇreba zpracov´ avat tyto soubory (databáze) sami. • zde je ˇc´ ast skuteˇcného souboru nsswitch.conf ze stroje u-us: passwd: group:

files ldap files ldap

# You must also set up the /etc/resolv.conf file for DNS name # server lookup. See resolv.conf(4). hosts: files dns # Note that IPv4 addresses are searched for in all of the # ipnodes databases before searching the hosts databases. ipnodes: files dns networks: protocols: rpc: ethers:

files files files files 67

Z´ısk´ av´ an´ı u ´ daj˚ u o uˇ zivatel´ıch/skupin´ ach • struct passwd *getpwnam(const char *name) vrac´ı strukturu reprezentuj´ıc´ı uˇzivatele. • struct passwd *getpwuid(uid t uid) vrac´ı strukturu reprezentuj´ıc´ı uˇzivatele podle UID. • void setpwent(void) • void endpwent(void) • struct passwd *getpwent(void) slouˇz´ı k proch´ azen´ı poloˇzek v databázi uˇzivatel˚ u. setpwent nastav´ı pozici na zaˇc´ atek, getpwent z´ıská dalˇs´ı poloˇzku, endpwent dealokuje prostˇredky pouˇzité pro procházen´ı seznamu.

• tyto funkce funguj´ı nez´ avisle na tom jak z jaké databáze byly z´ıskány informace o daném uˇzivateli. • vˇsechny tyto funkce jsou souˇcást´ı POSIX 1003.1-2008 (sekce XSH) • setpwent je tˇreba zavolat pˇred prvn´ım volán´ım getpwent • analogicky exituj´ı funkce getgrnam a getgrent které z´ıskávaj´ı informace o skupin´ ach. • pro prohled´ av´ an´ı a v´ ypis databaz´ı lze pouˇz´ıt program getent. Napˇr. k nalezen´ı z´ aznamu uˇzivatele a skupiny root: $ getent passwd root root:x:0:0:Super-User:/root:/sbin/sh $ getent group root root::0:

68

Testov´ an´ı pˇ r´ıstupov´ ych pr´ av • uˇzivatel je identifikov´ an ˇc´ıslem uˇzivatele (UID) a ˇc´ısly skupin, do kter´ ych patˇr´ı (primary GID, supplementary GIDs). • tuto identifikaci dˇed´ı kaˇzd´ y proces daného uˇzivatele. • soubor S m´ a vlastn´ıka (U IDS ) a skupinového vlastn´ıka (GIDS ). • algoritmus testov´ an´ı pˇr´ıstupov´ ych práv pro proces P (U IDP , GIDP , SU P G) a soubor S(U IDS , GIDS ): Jestliˇze

pak P roces má v˚ uˇci Souboru

if(U IDP == 0)

. . . vˇsechna práva

else if(U IDP == U IDS )

. . . práva vlastn´ıka

else if(GIDP == GIDS || GIDS ∈ SU P G)

. . . práva ˇclena skupiny . . . práva ostatn´ıch

else

• procesy superuˇzivatele root mohou mˇenit svoji uˇzivatelskou a skupinovou identitu. Toho vyuˇz´ıv´ a napˇr. proces login, kter´ y bˇeˇz´ı jako root a po zkontrolov´ an´ı jména a hesla spust´ı shell s uˇzivatelskou identitou (pomoc´ı volán´ı setuid – viz dalˇs´ı slajdy). • z algoritmu plyne, ˇze pro roota nen´ı relevantn´ı nastaven´ı práv (má vˇzdy neomezen´ y pˇr´ıstup). Pokud se shoduje uˇzivatel, nepouˇzij´ı se nikdy práva skupiny nebo ostatn´ıch, i kdyˇz povoluj´ı v´ıce neˇz uˇzivatelská práva. Podobnˇe pr´ ava ostatn´ıch se nepouˇzij´ı, jestliˇze se shoduje skupinová identita. Tedy pokud m´ a m˚ uj soubor nastaveny pr´ ava ---rwxrwx, nemohu ho ˇ c´ıst, zapisovat ani spustit, dokud nastaven´ı pr´ av nezmˇ en´ım. • nˇekteré systémy se odkl´ anˇej´ı od klasického modelu, kdy mnoho proces˚ u bˇeˇzelo pod uˇzivatelem s UID 0 a pˇri bezpeˇcnostn´ı chybˇe v takové aplikaci ˇcasto u ´toˇcn´ık z´ıskal vl´ adu nad cel´ ym systémem a zavádˇej´ı modely jako je least privilege model v Solarisu 10 nebo systrace v OpenBSD. • opakov´ an´ı z prvn´ıho roˇcn´ıku – aby uˇzivatel mohl smazat soubor, mus´ı m´ıt pr´ avo z´ apisu do daného adres´ aˇ re, protoˇze to je ten “soubor”, co se mˇen´ı. Pr´ ava k mazan´ emu souboru nejsou podstatn´ a; to ˇze vás shell upozorn´ı, ˇze maˇzete soubor, ke kterému nemáte právo zápisu, je pouze vˇec toho shellu. Je to logické – pokud si nastav´ıte soubor jako read-only, shell usuzuje, ˇze ho asi norm´ alnˇe mazat nechcete. Viz pˇr´ıklad pod t´ımto odstavcem. Unixov´ e syst´ emy nemaj´ı delete-like operaci na soubor, smazán´ı souboru nastane automaticky tehdy, kdyˇz na soubor nen´ı ˇzádn´ y odkaz z adresáˇrové struktury, a nikdo soubor jiˇz nemá otevˇren´ y.

69

$ whoami janp $ ls -ld janp-dir drwx-----2 janp staff 512 Mar 23 12:12 janp-dir/ $ ls -l janp-dir total 0 -rw-r--r-1 root root 0 Mar 23 12:11 root_wuz_here.txt $ rm janp-dir/root_wuz_here.txt rm: janp-dir/root_wuz_here.txt: override protection 644 (yes/no)? yes $ ls janp-dir/root_wuz_here.txt janp-dir/root_wuz_here.txt: No such file or directory • pokud ale root vytvoˇr´ı v adresáˇri janp-dir sv˚ uj podadresáˇr a tam vloˇz´ı sv˚ uj soubor, uˇzivatel janp uˇz nem˚ uˇze adresáˇr janp-dir a jeho obsah smazat, protoˇze: – podadres´ aˇr nelze smazat protoˇze nen´ı prázdn´ y – a dan´ y soubor nelze smazat z toho d˚ uvodu, ˇze janp nen´ı vlastn´ıkem podadres´ aˇre. • existuje situace, kdy ani pr´ avo zápisu (a execute) pro adresáˇr nestaˇc´ı. To se pouˇz´ıv´ a u tmp adres´ aˇr˚ u, do kter´ ych m˚ uˇze kaˇzd´ y psát, ale nen´ı ˇzádouc´ı situace, kdy by si uˇzivatelé navzájem mazali soubory. K tomu se pouˇz´ıvá tzv. sticky bit (01000). Systémy maj´ı vetˇsinou manuálovou stránku sticky, kde je funkce sticky bitu popsan´ a. Na v´ ypisu ls je oznaˇcovan´ y jako t: $ ls -ld /tmp drwxrwxrwt 7 root

root

515 Mar 23 12:22 /tmp

70

Re´ aln´ e a efektivn´ı UID/GID • u kaˇzdého procesu se rozliˇsuje: – re´ aln´ e UID (RUID) – skuteˇcn´ y vlastn´ık procesu – efektivn´ı UID (EUID) – uˇzivatel, jehoˇz práva proces pouˇz´ıv´ a – uschovan´ e UID (saved SUID) – p˚ uvodn´ı efektivn´ı UID • podobnˇe se rozliˇsuje reálné, efektivn´ı a uschované GID procesu. • obvykle plat´ı RUID==EUID && RGID==EGID. • prop˚ ujˇ cov´ an´ı pr´ av . . . spuˇstˇen´ı programu s nastaven´ ym SUID (set user ID) bitem zmˇen´ı EUID a saved UID procesu na UID vlastn´ıka programu, RUID se nezmˇen´ı. • podobnˇe SGID bit ovlivˇ nuje EGID procesu. • pˇ ri kontrole pˇ r´ıstupov´ ych pr´ av se pouˇ z´ıvaj´ı vˇ zdy EUID, EGID a supplementary GIDs

• bity SUID a SGID se pouˇz´ıvaj´ı u program˚ u, které potˇrebuj´ı vˇetˇs´ı pˇr´ıstupová pr´ ava, neˇz m´ a uˇzivatel, jenˇz je spouˇst´ı. Pˇr´ıkladem je program passwd, kter´ y mus´ı aktualizovat soubory /etc/passwd a /etc/shadow, kde ten prvn´ı nem˚ uˇze bˇeˇzn´ y uˇzivatel mˇenit a druh´ y z nich ani ˇc´ıst. Dalˇs´ı pˇr´ıklad je program su. Ten mus´ı m´ıt pr´ avo libovolnˇe zmˇenit uˇzivatelskou a skupinovou identitu, coˇz je privilegium proces˚ u s UID 0. • SUID a SGID programy by mˇely b´ yt peˇclivˇe naprogramovány, aby dovolily pouze ty operace, pro které jsou urˇceny, a neumoˇznily zneuˇz´ıt jejich privilegia pro neopr´ avnˇené akce (napˇr. spuˇstˇen´ı rootovského shellu). Zkuˇsenost ukazuje, ˇze tyto programy jsou jednou z nejˇcastˇejˇs´ıch pˇr´ıˇcin bezpeˇcnostn´ıch problém˚ u UNIXov´ ych systém˚ u. • z´ akladn´ım pravidlem pro SUID programy je: nepiˇ ste je pokud to nen´ı opravdu nezbytné. Je to typické m´ısto pro generován´ı bezpeˇcnostn´ıch chyb protoˇze dobˇre, tj. bezpeˇcnˇe, napsat sloˇzitˇejˇs´ı SUID program nen´ı jednoduché. • toto jsou pravidla pro zmˇ eny: – beˇzn´ y uˇzivatel nem˚ uˇze zmˇenit své RUID nebo uschované SUID (vyj´ımka je pˇri vol´ an´ı exec, viz strana 137) – proces m˚ uˇze vˇzdy zmˇenit své EUID na to z RUID nebo z uschovaného UID. Toto zaruˇcuje, ˇze v SUID programu je moˇzné libovolnˇe mˇenit EUID mezi t´ım p˚ uvodn´ım kter´ ym proces z´ıskal práva vlastn´ıka a mezi UID skuteˇcného uˇzivatele kter´ y dan´ y proces spustil.

71

– root m˚ uˇ ze vˇ sechno, a kdyˇz zmˇen´ı RUID, tak se zároveˇ n zmˇen´ı i uchované UID – nemˇelo by smysl mˇenit jen jedno z nich kdyˇz kterékoli m˚ uˇzete pouˇz´ıt pro nastaven´ı EUID.

Identifikace vlastn´ıka procesu • uid t getuid(void) vrac´ı re´ alné user ID volaj´ıc´ıho procesu. • uid t geteuid(void) vrac´ı efektivn´ı user ID volaj´ıc´ıho procesu. • gid t getgid(void) vrac´ı re´ alné group ID volaj´ıc´ıho procesu. • gid t getegid(void) vrac´ı efektivn´ı group ID volaj´ıc´ıho procesu. • int getgroups(int gidsz, gid t glist []) – do glist d´ a nejv´ yˇse gidsz supplementary group IDs volaj´ıc´ıho procesu a vr´ at´ı poˇcet vˇsech GIDs procesu.

• pro re´ alné UID je vol´ an´ı getuid, volán´ı getruid neexistuje • getgroups: kdyˇz gidsz == 0, jen vrát´ı poˇcet skupin. Kdyˇz 0 < gidsz < #skupin, vr´ at´ı -1. • v UNIXu je mnoho typ˚ u jako uid_t, gid_t, size_t, apod. Vesmˇes jsou to celoˇc´ıselné typy, ˇcasto je najdete v /usr/include/sys/types.h • Solaris m´ a pˇr´ıkaz pcred, kter´ y jednoduˇse zobraz´ı informace o identifikaci procesu: $ pcred 5464 5464: e/r/suid=1993 e/r/sgid=110 groups: 33541 41331 110

72

Zmˇ ena vlastn´ıka procesu • int setuid(uid t uid ); – v procesu s EUID == 0 nastav´ı RUID, EUID i saved-SUID na uid – pro ostatn´ı procesy nastavuje jen EUID, a uid mus´ı b´ yt bud’ rovné RUID nebo uschovanému SUID • int setgid(gid t gid ); obdoba setuid, nastavuje group-IDs procesu. • int setgroups(int ngroups, gid t *gidset ) nastavuje supplementary GIDs procesu, m˚ uˇze b´ yt pouˇzito jen superuˇzivatelsk´ ym procesem.

• o nastaven´ı UID pro proces s EUID 0 viz také poznámky na stranˇe 75. • co v´ yˇse uvedené tedy znamená: proces s efektivn´ımi právy superuˇzivatele m˚ uˇze libovolnˇe mˇenit identitu. Ostatn´ı procesory mohou pouze stˇr´ıdat svá re´ aln´ a a efektivn´ı pr´ ava. • program login vyuˇz´ıv´ a vol´ an´ı setuid • pokud chce process s UID == 0 zmˇenit svou identitu, mus´ı nejprve volat setgid a setgroups. Teprve pak lze zavolat setuid. Pˇri opaˇcném poˇrad´ı vol´ an´ı by proces po proveden´ı setuid uˇz nemˇel práva na setgid a setgroups. • setgroups nen´ı uvedeno v UNIX 98 ani UNIX 03. • RUID/EUID jsou uloˇzené v záznamu tabulky proces˚ u pro pˇr´ısluˇsn´ y proces a z´ aroveˇ n v tzv. u-area (viz napˇr´ıklad [Bach]). EUID v tabulce proces˚ u se naz´ yv´ a jiˇz zm´ınˇené uschované UID, neboli saved UID. Jak jiˇz bylo ˇreˇceno, uschované UID se pouˇz´ıv´ a pro kontrolu, kdyˇz se proces chce vrátit k EUID, se kter´ ym byl spuˇstˇen (po té, co doˇcasnˇe nastavil své EUID na UID uˇzivatele, kter´ y proces spustil, tj. na RUID). • pokud tedy jako root vytvoˇr´ıte SUID program a v nˇem zavoláte setuid pro jakéholi UID mimo 0, jiˇz se v programu k EUID==0 nem˚ uˇzete vrátit (je to logické – pˇredstavte si situaci, kdy se uˇzivatel loguje do systému). V tom pˇr´ıpadˇe byste museli pouˇz´ıt volán´ı seteuid, které nastavuje pouze EUID. • pˇr´ıklad: setuid/screate-file.c

73

Syst´ em soubor˚ u • adres´ aˇre tvoˇr´ı strom, spolu se soubory acyklick´ y graf (na jeden soubor m˚ uˇze existovat v´ıce odkaz˚ u). • kaˇzd´ y adres´ aˇr nav´ıc obsahuje odkaz na sebe ’.’ (teˇcka) a na nadˇrazen´ y adres´ aˇr ’..’ (dvˇe teˇcky). • pomoc´ı rozhran´ı systému soubor˚ u se pˇristupuje i k dalˇs´ım entit´ am v systému: – – – – – –

perifern´ı zaˇr´ızen´ı pojmenované roury sokety procesy (/proc) pamˇet’ (/dev/mem, /dev/kmem) pseudosoubory (/dev/tty, /dev/fd/0,. . . )

• z pohledu j´ adra je kaˇzd´ y obyˇcejn´ y soubor pole bajt˚ u. • vˇsechny (i s´ıt’ové) disky jsou zapojeny do jednoho stromu.

• zaˇr´ızen´ı, soubory v /proc, terminály, pamˇet’ atd. jsou vˇsechno jeden typ soubor˚ u - speci´ aln´ı soubory. Dalˇs´ı typy soubor˚ u - regulárn´ı soubor (hardlink), adres´ aˇr, pojmenovan´ a roura, socket, symbolick´ y link. • novˇe vytvoˇren´ y adres´ aˇr m´ a na sebe 2 odkazy – jeden z nadˇrazeného adresáˇre, a jeden s´ am na sebe, ’.’: $ mkdir test $ ls -ld test drwx-----2 janp

staff

512 Mar 23 12:46 test

• root m˚ uˇze v nˇekter´ ych systémech strukturu adresáˇr˚ u zacyklit, ale t´ım zmate utility pro proch´ azen´ı filesystému; moc se cyklické struktury nepouˇz´ıvaj´ı. Symbolické linky na adres´ aˇre funguj´ı vˇsude. • pojmenované roury (viz strana 100) lze pouˇz´ıt i mezi procesy, které nejsou pˇr´ıbuzensky spˇr´ıznˇené. Jinak funguj´ı stejnˇe jako nepojmenované roury. • zmiˇ nované sokety jsou v doménˇe UNIX, tj. slouˇz´ı pro komunikaci v rámci jednoho systému. Sokety z domény INET, pˇres které prob´ıhá s´ıt’ová komunikace, se v systému soubor˚ u neobjevuj´ı. S´ıt’ová komunikace zaˇc´ıná na stranˇe 185. • debuggery pouˇz´ıvaj´ı pamˇet’ové obrazy proces˚ u dostupné v /proc. Ve vˇetˇsinˇe unix-like systém˚ u obsahuje podstrom /proc u ´daje o jádru systému a bˇeˇz´ıc´ıch procesech ve formˇe textov´ ych soubor˚ u. 74

• dneˇsn´ı modern´ı unixy m´ıvaj´ı speciáln´ı filesystém devfs, jehoˇz obsah odráˇz´ı aktu´ aln´ı konfiguraci systému co se t´ yˇce pˇripojen´ ych zaˇr´ızen´ı. Tj. napˇr. pˇri pˇripojen´ı USB sticku se v /dev objev´ı pˇr´ısluˇsné diskové zaˇr´ızen´ı. Po fyzickém odpojen´ı zaˇr´ızen´ı odkaz z adresáˇrové struktury opˇet zmiz´ı.

Jednotn´ y hierarchick´ y syst´ em soubor˚ u /

dev etc

usr

home tty

• svazek (angl. file system) je ˇcást souborového systému, kterou lze samostatnˇe vytvoˇrit, pˇripojit, zruˇsit... Kaˇzd´ y filesystém m˚ uˇze m´ıt jinou vnitˇrn´ı strukturu (s5, ufs, ext2, xfs, atd.) a m˚ uˇze b´ yt uloˇzen na lokáln´ım disku nebo na jiném poˇc´ıtaˇci a pˇr´ıstupn´ y po s´ıti (nfs, afs). • po startu j´ adra je pˇripojen´ y jen koˇrenov´ y filesystém, dalˇs´ı filesystémy se zapojuj´ı do hierarchie na m´ısta adresáˇr˚ u pˇr´ıkazem mount. Tento pˇr´ıkaz je moˇzné spustit ruˇcnˇe (uˇzivatel root libovolnˇe, ostatn´ı pouze na nˇekter´ ych systémech a s omezen´ımi) nebo automaticky bˇehem inicializace systému, kdy se typicky ˇr´ıd´ı obsahem souboru /etc/fstab. Pˇred zastaven´ım systému se filesystémy odpojuj´ı pˇr´ıkazem umount. • dalˇs´ı moˇznost je pˇripojen´ı filesystému na ˇzádost pˇri prvn´ım pˇr´ıstupu a jeho odpojen´ı po urˇcité dobˇe neˇcinnosti. Tuto funkci zajiˇst’uje démon automounter (autofs, automount, amd). • UNIX nem´ a ˇz´ adné A, B, C, D. . . disky apod.

75

Typick´ a skladba adres´ aˇ r˚ u /bin

...

z´ akladn´ı systémové pˇr´ıkazy

/dev

...

speciáln´ı soubory (zaˇr´ızen´ı, devices)

/etc

...

konfiguraˇcn´ı adresáˇr

/lib

...

z´ akladn´ı systémové knihovny

/tmp

...

veˇrejn´ y adresáˇr pro doˇcasné soubory

/home

...

koˇren domovsk´ ych adresáˇr˚ u

/var/adm

...

administrativn´ı soubory (ne na BSD)

/usr/include

...

hlaviˇckové soubory pro C

/usr/local

...

lokálnˇe instalovan´ y software

/usr/man

...

manuálové stránky

/var/spool

...

spool (poˇsta, tisk,...)

• v /bin, /lib, /sbin jsou pˇr´ıkazy a knihovny potˇrebné pˇri startu systému, kdy je pˇripojen pouze koˇrenov´ y filesystém. Ostatn´ı pˇr´ıkazy a knihovny jsou typicky v /usr/bin, /usr/lib a /usr/sbin. /usr b´ yvá ˇcasto samostatn´ y filesystém, ˇc´ımˇz jeho obsah nen´ı dostupn´ y bˇehem startu systému. • s v sbin znaˇc´ı ,,system”, ne SUID. Jsou to binárky, u kter´ ych se pˇredpokládá, ˇze je bˇeˇzn´ y uˇzivatel nebude typicky potˇrebovat. • podstrom /usr obsahuje soubory, které se nemˇen´ı pˇri bˇeˇzném provozu a nejsou z´ avislé na konkrétn´ım poˇc´ıtaˇci. Proto by mˇel j´ıt sd´ılet read-only. Na své stanici doma ho ale vˇetˇsinou budete m´ıt read-write. • /lib typicky obsahuje knihovny potˇrebné pro programy z koˇrenového svazku. Pokud by vˇsechny knihovny byly v /usr/lib a /usr byl samostatn´ y svazek, problém s pˇripojen´ım /usr by kompletnˇe ochromil cel´ y systém, protoˇze by neˇslo spustit nic. Nˇekdy to systémy ˇreˇs´ı tak, ˇze koˇrenov´ y svazek obsahuje sadu z´ akladn´ıch program˚ u, které jsou staticky slinkované. Napˇr´ıklad FreeBSD má takové bin´ arky v adres´ aˇri /rescue, má ale i samostatné adresáˇre /lib a /usr/lib. • v podstromu /var jsou data, která se za provozu mˇen´ı a jsou specifická pro kaˇzd´ y poˇc´ıtaˇc. • r˚ uzné systémy i instalace jednoho systému se ˇcasto liˇs´ı. • hier(7) na FreeBSD a Linuxu popisuje adresáˇrovou hierarchii tohoto systému, Solaris m´ a filesystem(5).

76

Pˇ r´ıstup k perifern´ım zaˇ r´ızen´ım • adres´ aˇr /dev obsahuje speciáln´ı soubory zaˇr´ızen´ı. Proces otevˇre speci´ aln´ı soubor systémov´ ym volán´ım open() a dále komunikuje se zaˇr´ızen´ım pomoc´ı volán´ı read(), write(), ioctl(), apod. • speci´ aln´ı soubory se dˇel´ı na – znakov´ e . . . data se pˇren´ aˇs´ı pˇr´ımo mezi procesem a ovladaˇcem zaˇr´ızen´ı, napˇr. sériové porty – blokov´ e . . . data proch´ az´ı systémovou vyrovn´ avac´ı pamˇet´ı (buffer cache) po bloc´ıch pevnˇe dané velikosti, napˇr. disky

• speci´ aln´ı soubor identifikuje zaˇr´ızen´ı dvˇema ˇc´ısly – hlavn´ı (major) ˇ c´ıslo . . . ˇc´ıslo ovladaˇce v j´ adru – vedlejˇ s´ı (minor) ˇ c´ıslo . . . ˇc´ıslo v r´ amci jednoho ovladaˇce

• vyrovn´ avac´ı pamˇeti (cache) urychluj´ı perifern´ı operace. Pˇri ˇcten´ı se data hledaj´ı nejprve v bufferu. Teprve kdyˇz nejsou k dispozici, tak se ˇctou z disku. Pˇri pˇr´ıˇst´ım ˇcten´ı stejného bloku jsou data v bufferu. Pˇri zápisu se data uloˇz´ı do bufferu. Na disk je systém pˇrep´ıˇse pozdˇeji. Lze si vynutit i okamˇzit´ y zápis dat na disk. Dnes jiˇz cache typicky nen´ı samostatná struktura, vˇse je zastˇreˇseno modulem vitru´ aln´ı pamˇeti. • disky v UNIXu jsou obvykle pˇr´ıstupné pˇres znakové (pouˇz´ıvané pˇri mkfs – vytvoˇren´ı svazku – a fsck – kontrola konzistence) i blokové rozhran´ı (pouˇz´ıvané pˇri norm´ aln´ım provozu systému soubor˚ u). Nˇekteré systémy (FreeBSD) ale uˇz v /dev v˚ ubec soubory pro bloková zaˇr´ızen´ı nemaj´ı, pouze znaková. • dˇr´ıve musel administr´ ator systému po zmˇenˇe hardwarové konfigurace upravit obsah adres´ aˇre /dev skriptem MAKEDEV nebo ruˇcnˇe. Dnes (Linux, IRIX, FreeBSD, Solaris, . . . ) jiˇz speci´ aln´ı soubory dynamicky vznikaj´ı a zanikaj´ı podle toho, jak j´ adro detekuje pˇrid´ an´ı nebo odebrán´ı hardwarov´ ych komponent (viz devfs na stranˇe 79). • okamˇzit´ y z´ apis na disk lze vynutit pˇres O DIRECT command ve volán´ı fcntl.

77

Fyzick´ e uloˇ zen´ı syst´ emu soubor˚ u • syst´ em soubor˚ u (svazek, filesystem) lze vytvoˇrit na: – odd´ılu disku (partition) – ˇca ´st disku, na jednom disku m˚ uˇze b´ yt v´ıce odd´ıl˚ u – logick´ em odd´ılu (logical volume) – takto lze spojit v´ıce odd´ıl˚ u, které mohou b´ yt i na nˇekolika disc´ıch, do jednoho svazku.

• dalˇs´ı moˇznosti: striping, mirroring, RAID /home

/

disk 1

/usr

disk 2

disk 3

• v´ yraz systém soubor˚ u se pouˇz´ıvá v nˇekolika v´ yznamech: – jeden filesystém, tj. to, co vyrob´ı pˇr´ıkaz mkfs – cel´ a hierarchie pˇripojen´ ych svazk˚ u v systému (v´ ystup pˇr´ıkazu mount) – zp˚ usob organizace svazku (tj. typ fs) a tomu odpov´ıdaj´ıc´ı modul jádra, kter´ y s daty manipuluje (UFS2, Ext3, XFS, ...) • striping je od slova stripe, ne strip; podle toho se také vyslovuje. Znamená, ˇze za sebou n´ asleduj´ıc´ı bloky dat se ukládaj´ı paralelnˇe na r˚ uzné disky a t´ım se zvyˇsuje pˇrenosov´ a rychlost. • mirroring ukl´ ad´ a kopie dat v´ıce disk˚ u pro pˇr´ıpad havárie nˇekterého z nich. • paritn´ı disky: data se ukl´ adaj´ı na dva disky, na tˇret´ı se ukládá XOR prvn´ıch dvou, po hav´ arii libovolného disku jsou vˇsechna data stále ˇcitelná. • jednotlivé u ´rovnˇe RAID (Redundant Array of Inexpensive Disks) zahrnuj´ı striping, mirroring a vyuˇzit´ı paritn´ıch disk˚ u. • na terminologii je tˇreba d´ at velk´ y pozor. Napˇr. to, co se v DOS svˇetˇe naz´ yvá partition, se v BSD naz´ yv´ a slice. Tam jsou pak partitions definovány v rámci jednoho slice a v nich se vytváˇrej´ı filesystémy. • pokud v´ as to zaj´ım´ a nebo se s t´ım setkáváte v praxi, doporuˇcuji vaˇs´ı pozornosti ZFS, coˇz je filesystém a manaˇzer logick´ ych odd´ıl˚ u v jednom. Ze Solarisu se jiˇz dostal do FreeBSD od verze 7.0. M˚ uˇzete okamˇzitˇe zapomenout na jednotlivé disky, co je d˚ uleˇzité je pouze celková disková kapacita v systému.

78

Organizace syst´ emu soubor˚ u s5 blok ˇc. 0 zavádˇec´ı blok (boot block) 1 superblok 2 oblast i-uzl˚ u (i-nodes)

0

9 12

... oblast datových blok˚ u

• p˚ uvodn´ı UNIXov´ y systém soubor˚ u standardnˇe pouˇz´ıvan´ y do verze System V Release 3; v BSD se prim´ arnˇe pouˇz´ıval do verze 4.1 • vlastnosti: – bloky délky 512, 1024 nebo 2048 bajt˚ u – jedin´ y (neduplikovan´ y) superblok – datov´ y prostor pevnˇe rozdˇelen´ y na oblast i-uzl˚ u a oblast datových blok˚ u – pˇri velikosti bloku 1024 bajt˚ u byla teoretická velikost filesystému pˇres 16 GB • boot block – pro uloˇzen´ı zavadˇeˇce OSu • superblok – z´ akladn´ı informace o svazku: poˇcet blok˚ u pro i-uzly, poˇcet blok˚ u svazku, seznam voln´ ych blok˚ u (pokraˇcuje ve voln´ ych bloc´ıch), seznam voln´ ych i-uzl˚ u (po vyˇcerp´ an´ı se prohledává tabulka i-uzl˚ u), zámky pro seznamy voln´ ych blok˚ u a i-uzl˚ u, pˇr´ıznak modifikace pouˇz´ıvan´ y pro kontrolu korektn´ıho odpojen´ı svazku, ˇcas posledn´ı aktualizace, informace o zaˇr´ızen´ı • i-uzel – typ souboru, pˇr´ıstupová práva, vlastn´ık, skupina, ˇcasy posledn´ıho pˇr´ıstupu, modifikace dat a modifikace i-uzlu, poˇcet odkaz˚ u na soubor, velikost souboru, 10 odkaz˚ u na datové bloky a 3 odkazy na nepˇr´ımé bloky. Pozor na to, ˇze ˇcas vytvoˇren´ı souboru nen´ı uloˇzen. • maxim´ aln´ı velikost souboru: 2113674 blok˚ u, tj. pˇribliˇznˇe 1 GB pˇri pouˇzit´ı blok˚ u velikosti 512 B 79

• jména soubor˚ u – max. 14 znak˚ u (14 + 2 = 16, tedy mocnina dvou a tedy bezproblémové uloˇzen´ı adresáˇrov´ ych poloˇzek do blok˚ u) • pˇri pouˇzit´ı tohoto filesystému byla v´ ykonnost disk˚ u vyuˇzita jen cca na 2% a rychlost ˇcten´ı byla v ˇr´ adu jen nˇekolika des´ıtek kilobajt˚ u za sekundu (!!!) • pro srovn´ an´ı – MS-DOS 2.0 z roku 1983 podporoval pouze FAT12, poˇc´ıtaj´ıc´ı s maxim´ aln´ı velikost´ı filesystému 16 MB. Velikost svazku do 2 GB byla umoˇznˇena aˇz ve verzi 4.0 (1988); tato verze zároveˇ n zavedla diskové vyrovn´ avac´ı pamˇeti, tedy to, co UNIX má od svého vzniku v roce 1970.

Navigace v adres´ aˇ rov´ e struktuˇ re /etc/passwd

i-nodes i-node 2

data

i-node 37

i-node 71

. ..

2 2

. ..

37 2

etc

37

passwd

71

root:x:0:...

• kdyˇz cesta zaˇc´ın´ a znakem ’/’, zaˇc´ıná navigace v koˇrenovém adresáˇri, jinak zaˇcne v pracovn´ım adres´ aˇri procesu. • koˇrenov´ y adres´ aˇr m´ a typicky ˇc´ıslo 2. 0 je pro oznaˇcen´ı prázdného uzlu a 1 byla dˇr´ıve pouˇz´ıvan´ a pro soubor, do kterého se vkládaly vadné bloky, aby je systém uˇz d´ ale nepouˇz´ıval. • cesta ve které je v´ıce lom´ıtek za sebou je stále platná, tj. ///a///b///c je ekvivaletn´ı /a/b/c.

80

Linky hard link /var password

originál /etc 20

... 0

i-nodes

passwd

20

passwd

... ...

31

... ...

20 root:x:0:...

data

symbolický link /usr

31 ../etc/passwd

Hard linky lze vytv´ aˇret pouze v rámci jednoho (logického) filesystému.

• to co “norm´ alnˇe” vid´ıte pˇri v´ ypisu adresáˇr˚ u jsou vˇetˇsinou hardlinky, takˇze rozdˇelen´ı nen´ı na soubory, hardlinky a symbolické linky. Co se t´ yˇce soubor˚ u, jsou pouze hardlinky a symlinky. hardlink – – – – –

odkaz na stejn´ y i-uzel vlastnˇe druhé jméno souboru nen´ı rozd´ıl mezi originálem a hardlinkem lze vytv´ aˇret jen v rámci filesystému nelze vytv´ aˇret pro adresáˇre

symbolick´ y link (symlink, softlink) – pouze odkaz na skuteˇcnou cestu k souboru jiného typu (ls -l jej oznaˇcuje ’l’), tj. symbolick´ y link je typem odliˇsn´ y od bˇeˇzného souboru a jeho data obsahuj´ı obyˇcejn´ y ˇretˇezec – jméno cesty, at’ jiˇz relativn´ı nebo absolutn´ı – odliˇsné chov´ an´ı pro originál a link (napˇr. pˇri mazán´ı) – pozor na relativn´ı a absolutn´ı cesty pˇri pˇresouván´ı symbolického linku – m˚ uˇze ukazovat i na adresáˇr nebo na neexistuj´ıc´ı soubor • nejjednoduˇsˇs´ı zp˚ usob jak si ovˇeˇrit, zda dané dva linky ukazuj´ı na stejn´ y soubor na disku je pouˇz´ıt -i pˇrep´ınaˇc pˇr´ıkazu ls, kter´ y vám ukáˇze ˇc´ıslo indexového uzlu.

81

$ ls -i /etc/passwd 172789 /etc/passwd

Vylepˇ sen´ı syst´ emu soubor˚ u • c´ıl: sn´ıˇzen´ı fragmentace soubor˚ u, omezen´ı pohybu hlav disku um´ıstˇen´ım i-uzl˚ u a datov´ ych blok˚ u bl´ıˇz k sobˇe • UFS (Unix File System), p˚ uvodnˇe Berkeley FFS (Fast File System) • ˇclenˇen´ı na skupiny cylindr˚ u, kaˇzdá skupina obsahuje – kopii superbloku – ˇr´ıdic´ı blok skupiny – tabulku i-uzl˚ u – bitmapy voln´ ych i-uzl˚ u a datov´ ych blok˚ u – datové bloky • bloky velikosti 4 aˇz 8 kB, menˇs´ı ˇcásti do fragment˚ u blok˚ u • jména dlouh´ a 255 znak˚ u

• superblok v kaˇzdé cylinder skupinˇe posunut tak, aby superbloky nebyly na stejné plotnˇe. • dalˇs´ı typy filesystém˚ u: UFS2, Ext3, ReiserFS, XFS, ZFS aj. • v http://mff.devnull.cz/pvu/common/docs/filesystems.ps je porovnán´ı osmi r˚ uzn´ ych filesystém˚ u podle r˚ uzn´ ych implementaˇcn´ıch kritéri´ı; nezahrnuje v sobˇe ale v´ yvoj posledn´ıch let. • UFS byl st´ ale 32-bitov´ y, coˇz se odráˇzelo na maximáln´ı délce souboru i na maxim´ aln´ı velikosti filesystému. (Oznaˇcen´ı file systému jako 32-bitového znamen´ a, ˇze ˇc´ısla i-uzl˚ u jsou reprezentována jako 32-bitová. To pak dává teoretick´ y limit pro velikost filesystému.) • ˇzurn´ alov´ an´ı (XFS, Ext3, ReiserFS) – snaha o zmenˇsen´ı nebezpeˇc´ı ztráty dat v pˇr´ıpadˇe hav´ arie, urychlen´ı zotaven´ı po havárii • ZFS – modern´ı 128-bitov´ y filesystém vyvinut´ y v Sun Microsystems, od Solarisu 10, ted’ jiˇz také v FreeBSD 7.

82

V´ yvoj ve spr´ avˇ e adres´ aˇ rov´ ych poloˇ zek • maxim´ aln´ı délka jména souboru 14 znak˚ u nebyla dostaˇcuj´ıc´ı • FFS – délka aˇz 255; kaˇzdá poloˇzka zároveˇ n obsahuje i jej´ı délku • nové filesystémy pouˇz´ıvaj´ı pro vnitˇrn´ı strukturu adresáˇr˚ u r˚ uzné varianty B-strom˚ u – v´ yraznˇe zrychluje práci s adresáˇri obsahuj´ıc´ı velké mnoˇzstv´ı soubor˚ u – XFS, JFS, ReiserFS, . . . • UFS2 zav´ ad´ı zpˇetnˇe kompatibiln´ı tzv. dirhash pro zrychlen´ı pˇr´ıstupu k adres´ aˇr˚ um s velk´ ym poˇctem soubor˚ u

• dirhash pracuje tak, ˇze pˇri prvn´ım pˇreˇcten´ı adresáˇre se vytvoˇr´ı v pamˇeti hash struktura, n´ asledné pˇr´ıstupy do adresáˇre jsou pak srovnatelné se systémy pouˇz´ıvaj´ıc´ı B-stromy. T´ımto zp˚ usobem je dosaˇzeno zlepˇsen´ı bez toho, aby se mˇenila struktura filesystému na disku. Taková vylepˇsen´ı ale nelze v implementaci filesysému dˇelat do nekoneˇcna, nakonec je typicky nutná zmˇena on-disk form´ atu pro adaptaci na v´ ykonostn´ı poˇzadavky (nebo pˇrechod na jin´ y filesystém). • malé soubory se ˇcasto ukl´ adaj´ı v i-nodech, ˇc´ımˇz se uˇsetˇr´ı dalˇs´ı pˇr´ıstupy na disk

83

Virtu´ aln´ı syst´ em soubor˚ u (Virtual File System) struct struct struct struct struct file file file file file *file f vnode f vnode f vnode f vnode VNODE

VNODE

VNODE

VNODE

VNODE

v data INODE

v data INODE

v data INODE

v data INODE

v data INODE s realvp

ufs vnodeops ufs file system

s5 vnodeops s5 file system

spec vnodeops spec file system

• FFS uveden´ y ve 4.2BSD byl historicky druh´ y unixov´ y filesystém. Nˇekteˇr´ı dodavatelé unixov´ ych systém˚ u ho zaˇcali preferovat vzhledem k jeho lepˇs´ımu v´ ykonu a nov´ ym moˇznostem, jin´ y z˚ ustávali dále u s5fs z d˚ uvodu zpˇetné kompatibility. To d´ ale prohlubovalo problém jiˇz tak nedostateˇcné interoperability mezi r˚ uzn´ ymi unixov´ ymi systémy. Nˇekter´ ym aplikac´ım nav´ıc plnˇe nevyhovoval ani jeden z tˇechto filesystém˚ u. Postupnˇe se také objevovala potˇreba pracovat s ne-unixov´ ymi filesystémy, napˇr. FAT. A s rostouc´ı popularitou poˇc´ıtaˇcov´ ych s´ıt´ı se zvyˇsovala poptávka po sd´ılen´ı soubor˚ u mezi jednotliv´ ymi systémy, coˇz mˇelo za n´ asledek vznik distribuovan´ ych filesystém˚ u – napˇr. NFS (Network File System). • vzhledem k v´ yˇse popsané situaci bylo jen otázkou ˇcasu, kdy dojde k fundament´ aln´ım zmˇen´ am v infrastruktuˇre systému soubor˚ u, aby souˇcasnˇe podporoval v´ıce typ˚ u filesystém˚ u. Vzniklo nˇekolik r˚ uzn´ ych implementac´ı od r˚ uzn´ ych v´ yrobc˚ u, aˇz se nakonec de facto standardem stala VFS/vnode architektura od firmy Sun Microsystems. V dneˇsn´ı dobˇe prakticky vˇsechny unixové a unixlike systémy podporuj´ı VFS, i kdyˇz ˇcasto se vzájemnˇe nekompatibiln´ımi u ´pravami. VFS se poprvé objevilo v roce 1985 v Solarisu 2.0; brzy bylo pˇrevzato BSD – FFS s podporou VFS se zaˇcal naz´ yvat UFS. • hlavn´ı myˇslenka: kaˇzdému otevˇrenému souboru v systému pˇr´ısluˇs´ı struktura file; to by vlastnˇe byl jeden slot v námi jiˇz známé systémové tabulce otevˇren´ ych soubor˚ u. Ta ukazuje na vnode (virtual node). Vnode obsahuje ˇc´ ast nez´ avislou na konkrétn´ım systému soubor˚ u a ˇcást závislou, coˇz m˚ uˇze b´ yt napˇr´ıklad struktura inode. Ta je specifická pro kaˇzd´ y typ souborového systému. Kaˇ zd´ y typ filesyst´ emu implementuje pevnˇ e danou

84

sadu funkc´ı pro jednotliv´ e operace nad soubory, na kterou se odkazuj´ı vˇsechny virtu´ aln´ı uzly odpov´ıdaj´ıc´ı danému typu filesystému. Tato sada funkc´ı tedy definuje vnode interface. Kdyˇz tedy zavoláte napˇr´ıklad open, j´ adro zavol´ a pˇr´ısluˇsnou implementaci v závislosti na typu filesystému (napˇr. z modulu ext2fs). Implementaˇcnˇe závislá ˇcást struktury vnode je pˇr´ıstupná pouze z funkc´ı pˇr´ısluˇsného typu filesystému; jádro do n´ı tedy ,,nevid´ı” pˇr´ımo. Jak uvid´ıte na dalˇs´ım slajdu, existuje jeˇstˇe jedna sada funkc´ı, která se t´ yka pr´ ace s filesystémy jako takov´ ymi. Ta pak definuje VFS interface. Tyto dvˇ e sady spoleˇ cnˇ e tvoˇr´ı vnode/VFS rozhran´ı, kterému se bˇeˇznˇe ˇr´ıká jen VFS. • (nebudu zkouˇset) – u speci´ aln´ıch soubor˚ u je situace sloˇzitˇejˇs´ı, v SVR4 struktura file ukazuje na snode (shadow-special-vnode), kter´ y definuje operace se zaˇr´ızen´ım (pomoc´ı souborového systému spec) a prostˇrednictv´ım ukazatele aln´ y vnode pro operace se speciáln´ım souborem; s realvp se odkazuje na re´ ten je potˇreba napˇr´ıklad pro kontrolu práv pˇr´ıstupu. Kaˇzdému zaˇr´ızen´ı m˚ uˇze odpov´ıdat v´ıce speci´ aln´ıch soubor˚ u, a tedy v´ıce snodes a pˇr´ısluˇsn´ ych reáln´ ych vnodes. Vˇsechny takové snodes pro jedno zaˇr´ızen´ı maj´ı ukazatel s commonvp na jeden spoleˇcn´ y snode, to ale nen´ı na obrázku zachyceno. Pˇri otevˇren´ı speci´ aln´ıho souboru se hled´ a v hash tabulce snodes otevˇren´ ych zaˇr´ızen´ı poloˇzka odpov´ıdaj´ıc´ı speci´ aln´ımu souboru (podle major a minor ˇc´ısla zaˇr´ızen´ı). Kdyˇz snode nen´ı nalezen, vytvoˇr´ı se nov´ y. Tento snode se pak pouˇz´ıvá pˇri operac´ıch se zaˇr´ızen´ım. V´ıce viz napˇr´ıklad [Vahalia].

Hierarchie souborov´ ych syst´ em˚ u struct file f vnode

vfs mount list rootvfs VFS

v vfsp VNODE

VFS

vfs next vfs data

vfs data

root vnode super block

root vnode super block

vfs op

v op

vfs next

INODE

vnodeops vfs mountedhere

vfs op

vfs vnodecovered v vfsp

vfsops

VNODE

vfsops

v op INODE

vfssw[]

vsw vfsops

mount point in rootvfs

vnodeops

• struktura vfs obsahuje implementaˇcnˇe nezávislé informace o filesystému, nez´ avislé na konkrétn´ım typu filesystému, tedy podobnˇe jako vnode funguje 85

pro soubory. Tato struktura reprezentuje jeden konkrétn´ı fyzick´ y filesystém, aktu´ alnˇe pˇrimontovan´ y do hierarchie soubor˚ u. V tomto vázaném seznamu tedy m˚ uˇze b´ yt v´ıce struktur stejného typu souborového systému. • rootvfs – odkaz na root file system • vfsops – tabulka funkc´ı pro konkrétn´ı typ systému soubor˚ u • vfssw[] – pole odkaz˚ u na tabulky vfsops pro vˇsechny systémem podporované typy filesystém˚ u, z tabulky se vyb´ırá pˇri pˇripojován´ı svazku podle typu filesystému zadaného pˇri vol´ an´ı mount • v vfsp – odkaz z vnode na filesystém (strukturu vfs), na kterém leˇz´ı soubor reprezentovan´ y pomoc´ı vnode • v vfsmountedhere – pouze ve vnode, kter´ y reprezentuje mount point (adres´ aˇr, na kterém je pˇripojen koˇren jiného filesystému); odkazuje na strukturu vfs reprezentuj´ıc´ı pˇripojen´ y filesystém • v vnodecovered – odkaz na vnode adresáˇre, na kterém je filesystém pˇripojen

Otevˇ ren´ e soubory z pohledu j´ adra I. user file descriptor table file table : count 1 process A WRONLY

inode table

@ @ @ R count 1 @

Z Z Z Z

/etc/group

ZZ ~ count 2 3 RDONLY

Q

process B

- count 1

RDWR

Q QQ s count 3 : /etc/passwd

• toto je nejjednoduˇsˇs´ı pohled na tabulky v jádˇre které se t´ ykaj´ı soubor˚ u, je to pˇrevzato z [Bach]; dnes to je o nˇeco sloˇzitˇejˇs´ı, myˇslenka je ale poˇrád stejná. Realitˇe v´ıce se podobaj´ıc´ı obrázek je na pˇr´ıˇst´ım slajdu. • kaˇzd´ y proces m´ a svoji tabulku souborov´ ych deskriptor˚ u (user file descriptor table)

86

• z této tabulky je odkazovn´ ano na systémovou tabulku otevˇren´ ych soubor˚ u systému (file table; ano, tato tabulka je pouze jedna). Zde je mód otevˇren´ı souboru a také aktu´ aln´ı pozice v souboru. • z tabulky otevˇren´ ych soubor˚ u je odkazováno do tabulky naˇcten´ ych inod˚ uv pamˇeti. Dnes jsou to tzv. vnodes – virtual nodes, ale to v této chv´ıli nen´ı relevantn´ı. • tabulka otevˇren´ ych soubor˚ u systému, která vlastnˇe vytváˇr´ı o jednu u ´roveˇ n odkaz˚ u nav´ıc, je zde proto, aby r˚ uzné procesy mohly sd´ılet stejnou aktuáln´ı pozici v souboru. • pˇri otevˇren´ı souboru pomoc´ı volán´ı open se vˇzdy alokuje nov´ y slot v tabulce deskriptor˚ u a také v systémové tabulce otevˇren´ ych soubor˚ u (to je d˚ uleˇzité!). Sd´ılen´ı se pak v r´ amci jednoho procesu dosáhne duplikac´ı deskriptor˚ u, kdy v´ıce deskriptor˚ u sd´ıl´ı stejn´ y slot v tabulce otevˇren´ ych soubor˚ u systému nebo v pˇr´ıpadˇe r˚ uzn´ ych proces˚ u pak pomoc´ı vytvoˇren´ı nového procesu pomoc´ı vol´ an´ı fork(), viz strana 144.

Otevˇ ren´ e soubory z pohledu j´ adra II. struct proc uf next

uf next

struct ufchunk

struct ufchunk

... 2 1 0

... 2 1 0

struct ufchunk

u proc

u first

struct user p cred

... 2 1 0 uf ofile[] struct cred

f cred

f next

struct file

struct file

struct file

struct file

struct file

VNODE

VNODE

VNODE

VNODE

f prev

VNODE

struct file *file

f vnode

• struktury proc a user vytv´ aˇr´ı jádro pro kaˇzd´ y proces a drˇz´ı v nich sluˇzebn´ı informace o procesu. • struktura ufchunk obsahuje NFPCHUNK (obvykle 24) deskriptor˚ u soubor˚ u, po zaplnˇen´ı se alokuje dalˇs´ı ufchunk. • struktura file (otevˇren´ı souboru) obsahuje mód souboru (otevˇren pro ˇcten´ı, z´ apis, atd.), poˇcet deskriptor˚ u, které se na ni odkazuj´ı, ukazatel na vnode a

87

pozici v souboru. Jedno otevˇren´ı souboru m˚ uˇze b´ yt sd´ıleno v´ıce deskriptory, jestliˇze byl p˚ uvodn´ı deskriptor zkop´ırován, napˇr. volán´ım fork() nebo dup(). • struktura cred obsahuje uˇzivatelskou a skupinovou identitu procesu, kter´ y otevˇrel soubor. • jeden vnode odpov´ıdaj´ıc´ı jednomu souboru m˚ uˇze b´ yt sd´ılen nˇekolika strukturami file, pokud byl dan´ y soubor v´ıcekrát otevˇren. • ne vˇsechny vnodes jsou asociovány s tabulkou otevˇren´ ych soubor˚ u. Napˇr. pˇri spuˇstˇen´ı programu je potˇreba pˇristupovat do spustitelného souboru a proto se alokuje vnode.

Oprava konzistence souborov´ eho syst´ emu • pokud nen´ı filesystém pˇred zastaven´ım systému korektnˇe odpojen, mohou b´ yt data v nekonzistentn´ım stavu. • ke kontrole a opravˇe svazku slouˇz´ı pˇr´ıkaz fsck. Postupnˇe testuje moˇzné nekonzistence: – v´ıcen´ asobné odkazy na stejn´ y blok – odkazy na bloky mimo rozsah datové oblasti systému soubor˚ u – ˇspatn´ y poˇcet odkaz˚ u na i-uzly – nespr´ avn´ a velikost soubor˚ u a adresáˇr˚ u – neplatn´ y form´ at i-uzl˚ u – bloky které nejsou obsazené ani volné – chybn´ y obsah adres´ aˇr˚ u – neplatn´ y obsah superbloku • operace fsck je ˇcasovˇe nároˇcná. • ˇzurn´ alové (napˇr. XFS v IRIXu, Ext3 v Linuxu) a transakˇcn´ı (ZFS) systémy soubor˚ u nepotˇrebuj´ı fsck.

• data se pˇrepisuj´ı na disky z vyrovnávac´ıch pamˇet´ı se zpoˇzdˇen´ım. Uloˇzen´ı vˇsech vyrovn´ avac´ıch pamˇet´ı lze vynutit systémov´ ym volán´ım sync(). Periodicky vyrovn´ avac´ı pamˇeti ukládá zvláˇstn´ı systémov´ y proces (démon). • fsck kontroluje pouze metadata. pokud doˇslo k poruˇse dat samotn´ ych, nepozn´ a to, natoˇz aby s t´ım nˇeco mohl udˇelat. • zde je uk´ azka fsck na odpojen´ y filesystém: toor@shewolf:~# fsck /dev/ad0a ** /dev/ad0a ** Last Mounted on /mnt/flashcard ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames

88

** ** ** 24

Phase 3 - Check Connectivity Phase 4 - Check Reference Counts Phase 5 - Check Cyl groups files, 8848 used, 12951 free (7 frags, 1618 blocks, 0.0% fragmentation)

Dalˇ s´ı zp˚ usoby zajiˇ stˇ en´ı konzistence filesyst´ emu • tradiˇcn´ı UFS – synchronn´ı zápis metadat – aplikace vytv´ aˇrej´ıc´ı nov´ y soubor ˇceká na inicializaci inode na disku; tyto operace pracuj´ı rychlost´ı disku a ne rychlost´ı CPU – asynchronn´ı z´ apis ale ˇcastˇeji zp˚ usob´ı nekontistenci metadat • ˇreˇsen´ı problém˚ u s nekonzistenc´ı metadat na disku: – journalling – skupina na sobˇe závisl´ ych operac´ı se nejdˇr´ıve atomicky uloˇz´ı do ˇzurnálu; pˇri problémech se pak ˇzurnál m˚ uˇze “pˇrehr´ at” – bloky metadat se nejdˇr´ıve zap´ıˇs´ı do non-volatile pamˇeti – soft-updates – sleduje závislosti mezi ukazately na diskové struktury a zapisuje data na disk metodou write-back tak, ˇze data na disku jsou vˇzdy konzistentn´ı – ZFS je nov´ y filesystém v Solarisu, kter´ y pouˇz´ıvá copy-on-write transakˇcn´ı model

• filesystem metadata = inodes, directories, free block maps • ext2 dokonce defaultnˇe pouˇz´ıvá asynchronn´ı zápis metadat a je pˇri pouˇz´ıt´ı synchronn´ıho z´ apisu v´ yraznˇe pomalejˇs´ı neˇz UFS • z´ avislé operace jsou napˇr´ıklad smazán´ı poloˇzky z adresáˇre a smazán´ı diskového inode. Pokud by se stalo, ˇze se nejdˇr´ıve smaˇze diskov´ y inode a pak teprve poloˇzka v adres´ aˇri, pˇri v´ ypadku mezi tˇemito dvˇemi operacemi vniká nekonzistence – link ukazuje na diskov´ y soubor, kter´ y neexistuje. Nen´ı problém se tomuto vyhnout pˇri synchronn´ım zápisu metadat (v´ıme kdy a co zapisujeme, urˇcujeme tedy poˇrad´ı zápisu), ale pˇri metodˇe write-back je jiˇz nutné ˇreˇsit z´ avislosti jednotliv´ ych blok˚ u na sebe, protoˇze pˇri klasické synchronizaci vyrovn´ avac´ıch pamˇet´ı na disk jádro nezaj´ımá, kter´ y blok se zap´ıˇse dˇr´ıv a kter´ y pozdˇeji. • ˇcasto jsou bloky na sobˇe z´ avislé ve smyˇcce. Soft updates dokáˇze takovou smyˇcku rozb´ıt t´ım, ˇze provede roll-back a po zápisu pak roll-forward • v´ ykon soft updates je srovnateln´ y v´ ykonu UFS filesystému s asynchronn´ım z´ apisem metadat • teoreticky soft updates zaruˇcuj´ı, ˇze po rebootu nen´ı potˇreba pouˇz´ıt fsck, tj. ˇze filesystém bude v takovém stavu, ˇze je moˇzné nabootovat. Je vˇsak nutné 89

pouˇz´ıt tzv. background fsck pro opravy nezávaˇzn´ ych chyb – to je povaˇzováno st´ ale za velkou nev´ yhodu soft updates zvláˇstˇe s t´ım, jak rostou velikosti bˇeˇznˇe pouˇz´ıvan´ ych disk˚ u. Takovou chybou, která nebrán´ı nabootován´ı, ale je nutné ji odstranit je napˇr´ıklad blok, kter´ y je oznaˇcen jako pouˇzit´ y, ale ˇzádn´ y soubor ho nepouˇz´ıv´ a. • soft updates nejsou vˇzdy doporuˇcovány pro root filesystém. Problém je to, ˇze ztr´ ata metadat na root filesystému (viz 30-ti sekundová perioda zápisu) m˚ uˇze b´ yt v´ yraznˇe vˇetˇs´ı hrozbou zde neˇz na /usr, /home atd. Dalˇs´ı nev´ yhodou m˚ uˇze b´ yt i to, ˇze u soft updates mi smazán´ı velkého souboru hned neuvoln´ı m´ısto. • pˇr´ıklad: na bezpeˇcnou operaci rename potˇrebuju pˇri synchronn´ım zápisu metadat 4 z´ apisy – zv´ yˇsen´ı poˇctu odkaz˚ u v inode, vytvoˇren´ı nové adresáˇrové poloˇzky, smaz´ an´ı staré, a opˇetné sn´ıˇzen´ı poˇctu odkaz˚ u v inode. Kdykoli by systém spadnul, nenastane nebezpeˇcná situace. Napˇr´ıklad 2 odkazy z adres´ aˇr˚ u na inode s referenˇcn´ım poˇctem 1 je problém, protoˇze po zruˇsen´ı jednoho odkazu to bude vypadat, ˇze soubor je stále na disku, kdyˇz uˇz byla jeho data d´ avno smaz´ ana. Nen´ı teˇzké si asi pˇredstavit, co by to mohlo znamenat v pˇr´ıpadˇe, ˇze soubor obsahoval opravdu d˚ uleˇzitá data – napˇr´ıklad zálohu. Opaˇcn´ a situace, tj. jeden odkaz na inode s referenc´ı 2 sice také nen´ı správná situace, ale neohroˇzuje to moˇznost filesystém namontovat a normálnˇe pouˇz´ıvat. V nejhorˇs´ım se stane, ˇze soubor vypadá ˇze jiˇz na disku nen´ı a pˇritom stále existuje. U soft updates operace rename vytvoˇr´ı kruˇznici, protoˇze nejdˇr´ıve je potˇreba zapsat zv´ yˇsen´ı poˇctu referenc´ı, pak adresáˇrové bloky a poté sn´ıˇzen´ı referenc´ı. A protoˇze zv´ yˇsen´ı/sn´ıˇzen´ı se t´ yká stejného inode, tak je pˇri zápisu tˇreba udˇelat roll-back na (ˇreknˇeme) 2, zapsat inode na disk, zapsat bloky adres´ ar˚ u a pak roll-forward na poˇcet referenc´ı 1. Pˇri této akci je nad inodem drˇzen z´ amek, takˇze nikdo nenaˇcte starˇs´ı data. Je jednoduché ukázat, ˇze nelze zapsat ˇz´ adn´ y z tˇech tˇr´ı blok˚ u v kruˇznici tak, jak to je na konci operace rename, ˇze je opravdu nutn´ y ten roll-back – mohli bychom uvaˇzovat, ˇze inode se vlastnˇe nezmˇenil a nen´ı tˇreba ˇreˇsit zda se m˚ uˇze/nem˚ uˇze zapsat; zápis nového adres´ aˇrového odkazu bez zv´ yˇsen´ı poˇctu odkaz˚ u v inodu by nás totiˇz mohl dostat pˇresnˇe do situace, která je popsána o pár ˇrádk˚ u v´ yˇse.

90

Pˇ r´ıstupov´ a pr´ ava vlastn´ık (u) skupina (g) ostatn´ı (o) z }| { z }| { z }| { nejvyˇsˇs´ı bit

4 2

suid sgid sticky

1

r w x

• SGID pro soubor bez práva spuˇstˇen´ı pro skupinu v System V: kontrola z´ amk˚ u pˇri kaˇzdém pˇr´ıstupu (mandatory locking) • sticky bit pro adres´ aˇre: právo mazat a pˇrejmenovávat soubory maj´ı jen vlastn´ıci soubor˚ u • SGID pro adres´ aˇr: nové soubory budou m´ıt stejnou skupinu jako adres´ aˇr (System V; u BSD systém˚ u to funguje jinak, viz pozn´ amky)

• SGID pro adres´ aˇre u BSD systém˚ u zp˚ usob´ı, ˇze soubory a podadresáˇre vytvoˇrené v tomto adres´ aˇri budou m´ıt stejného majitele jako je majitel daného adres´ aˇre. Nutn´ ym pˇredpokladem je dále to, ˇze dan´ y UFS filesystém mus´ı b´ yt namontov´ an s suiddir pˇr´ıznakem a v jádru je option SUIDDIR (a to nen´ı default). Nav´ıc to nefunguje pro roota. Tato moˇznost existuje kv˚ uli Sambˇe a Nettalku. • sticky bit pro adres´ aˇre: pˇrejmenovat nebo smazat soubor m˚ uˇze jen jeho vlastn´ık (v nˇekter´ ych implementac´ıch staˇc´ı i právo zápisu do souboru), nestaˇc´ı pr´ avo z´ apisu do adres´ aˇre. Toto nastaven´ı se pouˇz´ıvá pro veˇrejné adresáˇre (napˇr. /tmp). • p˚ uvodnˇe mˇel sticky bit v´ yznam i pro spustitelné soubory: program s nastaven´ ym sticky bitem z˚ ustal po ukonˇcen´ı v pamˇeti a jeho opˇetovné spuˇstˇen´ı bylo rychlejˇs´ı. Dnes se sticky bit v tomto v´ yznamu uˇz nepouˇz´ıvá. • nˇekteré filesystémy (XFS, AFS, UFS2, ZFS) maj´ı tzv. access control lists (ACLs), které dovoluj´ı jemnˇejˇs´ı pˇridˇelován´ı práv jednotliv´ ym uˇzivatel˚ um a skupin´ am.

91

API pro soubory • pˇred pouˇzit´ım mus´ı proces kaˇzd´ y soubor nejprve otevˇr´ıt vol´ an´ım open() nebo creat(). • otevˇrené soubory jsou dostupné pˇres deskriptory soubor˚ u (file descriptors), ˇc´ıslované od 0, v´ıce deskriptor˚ u m˚ uˇze sd´ılet jedno otevˇ ren´ı souboru (mód ˇcten´ı/zápis, ukazatel pozice) • standardn´ı deskriptory: – 0 . . . standardn´ı vstup (jen pro ˇcten´ı) – 1 . . . standardn´ı v´ ystup (jen pro zápis) – 2 . . . chybov´ y v´ ystup (jen pro zápis) • ˇcten´ı a z´ apis z/do souboru: read(), write() • zmˇena pozice: lseek(), zavˇren´ı: close(), informace: stat(), ˇr´ıdic´ı funkce: fcntl(), práva: chmod(), . . .

• kaˇzd´ a funkce, kter´ a alokuje deskriptory (nejen open a creat, ale napˇr. i pipe, dup, socket) alokuje vˇzdy volné deskriptory s nejniˇzˇs´ım ˇc´ıslem. • proces dˇed´ı otevˇrené soubory od rodiˇce, tyto soubory nemus´ı znovu otv´ırat. Obvykle (ale ne vˇzdy) proces dostane otevˇrené alespoˇ n deskriptory 0, 1 a 2. • funkce ze souboru stdio.h (napˇr. fopen, fprintf, fscanf) a odkazy na soubory pomoc´ı ukazatele na FILE jsou definovány ve standardn´ı knihovnˇe a pro svoj´ı ˇcinnost pouˇz´ıvaj´ı volán´ı jádra (napˇr. open, write, read). My se nebudeme knihovnou stdio zab´ yvat.

92

Otevˇ ren´ı souboru: open() int open(const char *path, int oflag, ... ); • otevˇre soubor dan´ y jménem (cestou) path, vrát´ı ˇc´ıslo jeho deskriptoru (pouˇzije prvn´ı volné), oflag je OR-kombinace pˇr´ıznak˚ u – O RDONLY/O WRONLY/O RDWR . . . otevˇr´ıt pouze pro ˇcten´ı / pouze pro z´ apis / pro ˇcten´ı i zápis – O APPEND . . . pˇripojován´ı na konec – O CREAT . . . vytvoˇrit, kdyˇz neexistuje – O EXCL . . . chyba, kdyˇz existuje (pouˇzit´ı s O CREATE) – O TRUNC . . . zruˇsit pˇredchoz´ı obsah (právo zápisu nutné) – ... • pˇri O CREAT definuje tˇret´ı parametr mode pˇr´ıstupová práva

• pˇri pouˇzit´ı O CREAT se mode jeˇstˇe modifikuje podle nastaven´ı aktuáln´ı masky, které se mˇen´ı vol´ an´ım umask. Defaultn´ı hodnota je typicky 022. Doporuˇcuji se zamyslet, zda ji ve vaˇsem shell profile skriptu nenastavit na 077. To ale nikdy nedˇelejte pro roota, jinak skonˇc´ıte s podivnˇe se chovaj´ıc´ım systémem – nainstalovan´ y software nebude moct spustit pod bˇeˇzn´ ym uˇzivatelem, to co dˇr´ıve fungovalo fungovat pˇrestane apod. • mode nem´ a defaultn´ı hodnotu, tj. vezme se to, co je na zásobn´ıku i kdyˇz tento parametr nen´ı pˇr´ıtomen! Pˇr´ıznaky i mód jsou uloˇzeny v systémové tabulce otevˇren´ ych soubor˚ u. • pokud se znovu pouˇzije dˇr´ıve vyuˇz´ıvaná poloˇzka v tabulce deskriptor˚ u nebo v tabulce otevˇren´ ych soubor˚ u, vˇse potˇrebné se vynuluje (pozice v souboru, flagy deskriptoru, . . . ) • existuj´ı jeˇstˇe dalˇs´ı nastavitelné pˇr´ıznaky: – O SYNC (O DSYNC, O RSYNC – nen´ı na BSD) . . . operace se souborem skonˇc´ı aˇz po fyzickém uloˇzen´ı dat (synchronized I/O) – O NOCTTY . . . pˇri otv´ır´ an´ı terminálu procesem, kter´ y nemá ˇr´ıdic´ı termin´ al, se tento termin´ al nestane ˇr´ıd´ıc´ım terminálem procesu – O NONBLOCK . . . pokud nelze ˇcten´ı nebo zápis provést okamˇzitˇe, volán´ı read/write skonˇc´ı s chybou m´ısto zablokován´ı procesu • v pˇr´ıstupov´ ych pr´ avech se vynuluj´ı ty bity, které jsou nastavené pomoc´ı umask.

93

• pro ˇcten´ı a z´ apis nelze pouˇz´ıt O RDONLY | O WRONLY, protoˇze implementace pouˇzily 0 pro read-only flag. Norma proto definuje, ˇze aplikace mus´ı pouˇz´ıt pr´ avˇe jeden z tˇechto tˇr´ı flag˚ u. • je moˇzné otevˇr´ıt a z´ aroveˇ n vytvoˇrit soubor pro zápis tak, ˇze jeho mód zápis nedovoluje. Pˇri pˇr´ıˇst´ım otevˇren´ı souboru se ale jiˇz tento mód uplatn´ı pˇri kontrole pˇr´ıstupu a pro z´ apis jej otevˇr´ıt nep˚ ujde. Pro O TRUNC také plat´ı, ˇze mus´ıte m´ıt pro dan´ y soubor právo zápisu.

Vytvoˇ ren´ı souboru int creat(const char *path, mode t mode ); • open() s pˇr´ıznakem O CREAT vytvoˇr´ı soubor, pokud jeˇstˇe neexistuje. V zadané hodnotˇe pˇr´ıstupov´ ych práv se vynuluj´ı bity, které byly nastaveny pomoc´ı funkce mode t umask(mode t cmask ); • funkce je ekvivalentn´ı volán´ı open(path, O WRONLY|O CREAT|O TRUNC, mode); int mknod(const char *path, mode t mode, dev t dev ); • vytvoˇr´ı speci´ aln´ı soubor zaˇr´ızen´ı. int mkfifo(const char *path, mode t mode ); • vytvoˇr´ı pojmenovanou rouru.

• Vol´ an´ı vrac´ı nejniˇzˇs´ı deskriptor, kter´ y v dané chv´ıli nebyl otevˇren´ y pro proces • open dok´ aˇze otevˇr´ıt regul´ arn´ı soubor, zaˇr´ızen´ı i pojmenovanou rouru, ale vytvoˇrit dok´ aˇze jen regul´ arn´ı soubor; pro ostatn´ı typy soubor˚ u je nutné pouˇz´ıt zde uveden´ a speci´ aln´ı vol´ an´ı. • Test pomoc´ı pˇr´ıznaku O EXCL na to, zda soubor existuje, a jeho pˇr´ıpadné vytvoˇren´ı je atomick´ a operace. Toho se vyuˇz´ıvá pˇri pouˇz´ıván´ı lock soubor˚ u. Ze slajdu je vidˇet, ˇze tento test je moˇzné provést jen pomoc´ı volán´ı open, ne creat. • Speci´ aln´ı soubory m˚ uˇze vytváˇret pouze root, protoˇze se pomoc´ı nich definuj´ı pˇr´ıstupov´ a pr´ ava k perifern´ım zaˇr´ızen´ım. • Povolené hodnoty pro mode je moˇzné nalézt vˇetˇsinou v manuálové stránkce pro chmod(2), a urˇcitˇe je naleznete i v hlaviˇckovém souboru stat.h, kde mus´ı b´ yt podle normy definované.

94

ˇ Cten´ ı a z´ apis soubor˚ u: read(), write() ssize t read(int fildes, void *buf, size t nbyte ); • z otevˇreného souboru s ˇc´ıslem deskriptoru fildes pˇreˇcte od aktu´ aln´ı pozice max. nbyte bajt˚ u dat a uloˇz´ı je od adresy buf. • vrac´ı poˇcet skuteˇcnˇe pˇreˇcten´ ych bajt˚ u (<= nbyte), 0 znamená konec souboru. ssize t write(int fildes, const void *buf, size t nbyte ); • do otevˇreného souboru s ˇc´ıslem deskriptoru fildes zap´ıˇse na aktu´ aln´ı pozici max. nbyte bajt˚ u dat uloˇzen´ ych od adresy buf. • vrac´ı velikost skuteˇcnˇe zapsan´ ych dat (<= nbyte).

• pro UNIX je kaˇzd´ y soubor posloupnost bajt˚ u bez dalˇs´ı vnitˇrn´ı struktury. • chov´ an´ı read a write z´ avis´ı na typu souboru (regulárn´ı, zaˇr´ızen´ı, roura, soket) a na tom, zda je soubor v blokuj´ıc´ım nebo neblokuj´ıc´ım módu (flag O NONBLOCK pˇri otevˇren´ı souboru, viz strana 99). • pro obˇe vol´ an´ı existuje nˇekolik zásadn´ıch rohov´ ych pˇr´ıpad˚ u a následuj´ıc´ı informace jsou v´ yn ˇatkem z manu´ alov´ ych stránek. Pokud si nejste jisti, doporuˇcuji se pod´ıvat pˇr´ımo do normy (POSIX 1003.1, sekce XSH, ˇcást System Interfaces). • vol´ an´ı read vr´ at´ı nenulov´ y poˇcet bajt˚ u menˇs´ı neˇz nbyte, pokud v souboru zb´ yv´ a ménˇe neˇz nbyte bajt˚ u, nebo volán´ı bylo pˇreruˇseno signálem, nebo soubor je roura, zaˇr´ızen´ı ˇci soket a aktuálnˇe je k dispozici ménˇe neˇz nbyte bajt˚ u. Pˇri neexistenci dat se blokuj´ıc´ı read zablokuje, dokud se nˇejaká data neobjev´ı, neblokuj´ıc´ı read vrát´ı -1 a nastav´ı errno na EAGAIN. • vol´ an´ı write vr´ at´ı nenulov´ y poˇcet bajt˚ u menˇs´ı neˇz nbyte, jestliˇze se do souboru nevejde v´ıc dat (napˇr. zaplnˇen´ y disk), zápis je pˇreruˇsen signálem nebo je nastaveno O_NONBLOCK a do roury, soketu nebo zaˇr´ızen´ı se vejde pouze ˇcást zapisovan´ ych dat. Bez O_NONBLOCK se ˇceká, dokud se nepodaˇr´ı zapsat vˇse. Pokud nelze aktu´ alnˇe zapsat nic, blokuj´ıc´ı write se zablokuje, dokud nen´ı moˇzné zapisovat, neblokuj´ıc´ı write vrát´ı -1 a nastav´ı errno na EAGAIN. • d˚ uleˇ zit´ e v´ yjimky vzhledem k rour´ am jsou uvedeny na stranˇe 104. • kdyˇz read nebo write vr´ at´ı ménˇe neˇz nbyte z d˚ uvodu chyby, opakované vol´ an´ı téˇze funkce vr´ at´ı -1 a nastav´ı kód chyby v errno. 95

• pˇreruˇsen´ı read, write sign´ alem dˇr´ıv, neˇz se podaˇr´ı pˇreˇc´ıst, resp. zapsat aspoˇ n jeden bajt, zp˚ usob´ı n´ avrat s hodnotou -1 a nastaven´ı errno na EINTR. Pozor na to, ˇze zde je rozd´ıl proti situaci, kdy pˇred doruˇcen´ım signálu podaˇr´ı pˇreˇc´ıst nebo zapsat alespoˇ n jeden bajt (viz v´ yˇse). • pˇr´ıznak otevˇren´ı souboru O_APPEND zajist´ı atomick´ y zápis na konec souboru (pouze na lok´ aln´ım disku), tj. kaˇ zd´ y zápis se provede na konec souboru (tzv. append-only soubor).

Uzavˇ ren´ı souboru: close() int close(int fildes ); • uvoln´ı deskriptor fildes, pokud to byl posledn´ı deskriptor, kter´ y odkazoval na otevˇren´ı souboru, zavˇre soubor a uvoln´ı z´ aznam o otevˇren´ı souboru. • kdyˇz je poˇcet odkaz˚ u na soubor 0, jádro uvoln´ı data souboru. Tedy i po zruˇsen´ı vˇsech odkaz˚ u (jmen) mohou se souborem pracovat procesy, které ho maj´ı otevˇren´ y. Soubor se smaˇze, aˇz kdyˇz ho zavˇre posledn´ı proces. • kdyˇz se zavˇre posledn´ı deskriptor roury, vˇsechna zb´ yvaj´ıc´ı data v rouˇre se zruˇs´ı. • pˇri skonˇcen´ı procesu se automaticky provede close() na vˇsechny deskriptory.

• Pokud proces potˇrebuje doˇcasn´ y soubor, m˚ uˇze ho vytvoˇrit, ihned smazat a pak s n´ım pracovat pˇres existuj´ıc´ı deskriptor (tento deskriptor lze pˇredat synovsk´ ym proces˚ um). Kdyˇz je takov´ y soubor zavˇren vˇsemi procesy, jádro smaˇze jeho data z disku. • I operace close m˚ uˇze selhat. Napˇr. nˇekteré filesystémy zapisuj´ı data na disk aˇz v okamˇziku zavˇren´ı souboru, kdyˇz zápis skonˇc´ı chybou, close vrát´ı -1. • Otev´ır´ an´ı soubor˚ u a nezav´ır´ an´ı je pˇri ukonˇcen´ı práce s nimi vede k alokované pamˇeti, kterou jiˇz nem´ ame jak uvolnit (ztratili jsme na ni odkaz) – situace kde takto pamˇet’ “ztr´ ac´ıme” se naz´ yvá memory leak. Nen´ı to u ´plnˇe pˇresnˇe to, jak se typicky ch´ ape memory leak (pamˇet, na kterou jsme ztratili ukazatel), ale n´ asledky jsou podobné. • Pˇr´ıklad na jednoduch´ y cat(1) program: read/cat.c

96

Pˇ r´ıklad: kop´ırov´ an´ı soubor˚ u #include <sys/types.h> #include int main(int argc, char *argv[]) { char buf[4096]; int inf, outf; ssize t ilen; inf = open(argv[1], O RDONLY); outf = creat(argv[2], 0666); while ((ilen = read(inf, buf, 4096)) > 0) write(outf, buf, ilen); close(inf); close(outf); return (0); }

• Tento pˇr´ıklad je kompletn´ı! Staˇc´ı provést cut-and-paste, pˇreloˇzit a spustit. Nutno poznamenat, ˇze pro u ´ˇcely pouˇzit´ı pouze jednoho slajdu se netestuj´ı ˇz´ adné chyby, vˇcetnˇe ignorován´ı toho, ˇze uˇzivatel m˚ uˇze program spustit bez parametr˚ u, coˇz zp˚ usob´ı pokus o pˇr´ıstup do pamˇeti na m´ısto, které neobsahuje oˇcek´ avan´ a data. To pak na nˇekter´ ych systémech m˚ uˇze zp˚ usobit core dump. • Je neefektivn´ı ˇc´ıst a zapisovat soubor po jednotliv´ ych bajtech, protoˇze kaˇzdé systémové vol´ an´ı m´ a jist´ y overhead, nezávisl´ y na velikosti zpracovávaného bloku. Lepˇs´ı je proto najednou zpracovávat rozumnˇe velké bloky, napˇr´ıklad 864KB. Pˇrechoz´ı pˇr´ıklad read/cat.c má pˇrep´ınaˇc -b pro nastaven´ı velikosti bloku pro ˇcten´ı; zkuste s (a bez) -b 1 a zmˇeˇrte pomoc´ı time(1). Uvid´ıte velk´ y rozd´ıl. • Pokud potˇrebujete pracovat s mal´ ymi ˇcástmi/buffery, je lepˇs´ı pouˇz´ıt stream orintované knihovn´ı funkce fopen, fread, . . . které data vnitˇrnˇe bufferuj´ı. • Vˇsimnˇete si, ˇze vˇzdy zapisujeme jen tolik bajt˚ u, kolik jsme jich naˇcetli.

97

Pr´ ace s pojmenovanou rourou • nemus´ı b´ yt moˇzné vytvoˇrit FIFO na s´ıt’ovém filesystému (NFS, AFS) • je nutné zn´ at sémantiku otev´ırán´ı pojmenované roury: – otevˇren´ı roury pouze pro ˇcten´ı se zablokuje do té doby, dokud se neobjev´ı zapisovatel (pokud jiˇz neexistuje) – otevˇren´ı roury pouze pro zápis se zablokuje do té doby, dokud se neobjev´ı ˇctenáˇr (pokud jiˇz neexistuje) – toto chov´ an´ı je moˇzné ovlivnit flagem O NONBLOCK • sémantika ˇcten´ı a z´ apisu je jeˇstˇe o nˇeco sloˇzitˇejˇs´ı, vˇenujte velkou pozornost pozn´ amkám pod t´ımto slajdem – a je to stejné jako u nepojmenované roury

• Co se t´ yˇce vytvoˇren´ı pojmenované roury, mluv´ıme zde o volán´ı mkfifo ze strany 100. Pouˇzit´ı nepojmenované roury je popsané na stranˇe 143. ˇ aˇr je proces, kter´ • Cten´ y otevˇre soubor (i) pro ˇcten´ı, zapisovatel je proces, kter´ y otevˇre soubor (i) pro zápis. • Je moˇzné otevˇr´ıt rouru pro zápis i ˇcten´ı stejn´ ym procesem najednou, aniˇz by pˇredt´ım existoval ˇcten´ aˇr nebo zapisovatel. Proces pak m˚ uˇze do roury zapisovat a z opaˇcného konce ˇc´ıst, co do roury napsal. • Pokud rouru nem´ a ˇz´ adn´ y proces otevˇrenou pro zápis, pro okamˇzité vrácen´ı deskriptoru pouze pro ˇcten´ı je nutné otevˇ r´ıt rouru s flagem O NONBLOCK, proces se jinak na rouˇre zablokuje ˇcekán´ım na zapisovatele. Pozor ale na to, ˇze pokus o ˇ cten´ı z roury bez zapisovatele okamˇzitˇe vrát´ı 0 jako indikaci konce souboru; proces se nezablokuje ˇ cek´ an´ım na zapisovatele, bez ohledu na to zda byl soubor otevˇren v blokovac´ım ˇci neblokovac´ım módu. Pˇri z´ apisu do roury bez ˇcten´ aˇre (tj. zapisovatel otevˇrel rouru jeˇstˇe v dobˇe, kdy ˇcten´ aˇr existoval, viz n´ asleduj´ıc´ı odstavec) poˇsle kernel procesu signál SIGPIPE (“broken pipe”): bash$ dd if=/dev/zero | date Sun Mar 2 01:03:38 CET 2008 bash$ echo ${PIPESTATUS[0]} 141 bash$ kill -l 141 PIPE

98

• v pˇr´ıpadˇe otev´ır´ an´ı pouze pro zápis s O NONBLOCK bez existuj´ıc´ıho ˇctenáˇre se vr´ at´ı chyba a errno se nastav´ı na ENXIO. Tato asymetrie je snahou, aby v rouˇre nebyla data, kter´ a nebudou v krátké dobˇe pˇreˇctena – systém nemá zp˚ usob, jak uschov´ avat data v rouˇre bez ˇcasového omezen´ı. Bez O NONBLOCK flagu se proces zablokuje ˇcekán´ım na ˇctenáˇre. Asymetri´ı je m´ınˇeno to, ˇze systému nevad´ı ˇcten´ aˇri bez zapisovatel˚ u, ale nechce m´ıt zapisovatele bez ˇcten´ aˇr˚ u. I tato situace se m˚ uˇze stát, viz pˇredchoz´ı odstavec, ale tam to jinak ˇreˇsit nelze. • z uvedeného tedy vypl´ yv´ a, ˇze pokud chcete vytvoˇrit proces, kter´ y ˇceká na pojmenované rouˇre a vykon´ av´ a poˇzadavky od r˚ uzn´ ych proces˚ u-zapisovatel˚ u (od kaˇzdého jeden), mus´ıte ji otevˇr´ıt s flagem O RDWR i kdyˇz do roury nehodláte zapisovat; jinak po prvn´ım zablokován´ı v open pˇri ˇcekán´ı na otevˇren´ı roury zapisovatelem by dalˇs´ı vol´ an´ı read pro akceptován´ı dalˇs´ıho poˇzadavku typicky vr´ atilo 0, pokud by n´ ahodou roura nebyla mezit´ım pro zápis otevˇrena dalˇs´ım procesem. y jako atomick´ y, tj. • z´ apis maxim´ aln´ı velikosti PIPE BUF (limits.h) je zaruˇcen´ data nesm´ı b´ yt proloˇzena daty jin´ ych zapisuj´ıc´ıch proces˚ u. Napˇr. v Solarisu 11 to je to 5120 bajt˚ u, ve FreeBSD 5.4 je to 512 bajt˚ u. Pokud zapisujete v´ıce, m˚ uˇze se to st´ at. Z´ aroveˇ n plat´ı, ˇze pokud se zapisuje ménˇe neˇz PIPE BUF bajt˚ u, zap´ıˇsou se vˇzdy najednou, a pokud je nastaveno O NONBLOCK a nelze toho dos´ ahnout, vr´ at´ı se chyba. • roura nem´ a pozici v souboru, zápis tak vˇzdy pˇridává na konec. • stejnˇe se vzhledem ke ˇcten´ı a zápisu chová i nepojmenovaná roura, viz strana 143.

Nastaven´ı pozice: lseek() off t lseek(int fildes, off t offset, int whence ); • nastav´ı pozici pro ˇcten´ı a zápis v otevˇreném souboru daném ˇc´ıslem deskriptoru fildes na hodnotu offset. • podle hodnoty whence se offset poˇc´ıtá: – SEEK SET . . . od zaˇcátku souboru – SEEK CUR . . . od aktuáln´ı pozice – SEEK END . . . od konce souboru • vrac´ı v´ yslednou pozici poˇc´ıtanou od zaˇcátku souboru. • lseek(fildes, 0, SEEK CUR) pouze vrát´ı aktuáln´ı pozici.

99

• Poˇc´ıt´ a se od 0, tj. offset 0 je prvn´ı bajt souboru. Tam, kde to má smysl, je moˇzné pro offset pouˇz´ıt i záporné ˇc´ıslo. Pˇr´ıklad: read/lseek.c . • Lze se pˇresunout i na pozici za koncem souboru. Pokud se pak provede zápis, soubor se prodlouˇz´ı a v pˇreskoˇcené ˇcásti budou samé nuly (samotné lseek nestaˇc´ı). Nˇekteré filesystémy takové bloky cel´ ych nul pro u ´sporu m´ısta neukl´ adaj´ı. • Velikost souboru je moˇzné zjistit pomoc´ı lseek(fildes, 0, SEEK END). • Nejˇcastˇejˇs´ı operace s lseek jsou tˇ ri: nastaven´ı konkrétn´ı pozice od zaˇcátku souboru, nastaven´ı pozice na konec souboru a zjiˇstˇen´ı aktuáln´ı pozice v souboru (0 spoleˇcnˇe se SEEK CUR) • Pˇri pouˇzit´ı lseek se ˇz´ adné I/O neprovede, tj. ˇzádn´ y pˇr´ıkaz se nepoˇsle na ˇradiˇc disku. • lseek nemus´ı slouˇzit jen pro operace read a write, ale také pro následnou operaci lseek • Seekov´ an´ı a z´ apis m˚ uˇze vést k problém˚ um se zálohami. Pˇr´ıklad: read/big-file.c demonstruje, ˇze pˇresun souboru s ”d´ırami”(tzv. sparse file) m˚ uˇze vést k n´ ar˚ ustu velikosti souboru co se t´ yˇce blok˚ u alokovan´ ych file systémem. Chován´ı z´ aleˇz´ı na kombinaci operaˇcn´ıho systému, archivn´ıho programu a file systému (a jejich verz´ı). Nˇekteré programy maj´ı pˇrep´ınaˇce, které umoˇzn´ı d´ıry zachovat (napˇr. dd s conv=sparse, tar s -S, rsync s --sparse, atd.). • Pozor na pˇrehozen´ı parametr˚ u. Druhá ˇrádka samostatnˇe vypadá OK, ale má pˇrehozené parametry. SEEK SET je nav´ıc 0 a SEEK CUR je 1, takˇze vás to nikam neposune a nic ˇspatného se nestane, a o to je horˇs´ı to pak naj´ıt. lseek(fd, 1, SEEK_SET) lseek(fd, SEEK_SET, 1)

100

Zmˇ ena velikosti: truncate() int truncate(const char *path, off t length ); int ftruncate(int fildes, off t length ); • zmˇen´ı délku souboru zadaného cestou nebo ˇc´ıslem deskriptoru na poˇzadovanou hodnotu. • pˇri zkr´ acen´ı souboru zruˇs´ı nadbyteˇcná data. • standard ponech´ av´ a nespecifikované, jestli funguje prodlouˇzen´ı souboru (s vyplnˇen´ım pˇridaného u ´seku nulami). Proto je lepˇs´ı k prodlouˇzen´ı souboru pouˇz´ıt: char buf = ’\0’; lseek(fildes, length - 1, SEEK_SET); write(fildes, &buf, 1);

• zruˇsit veˇsker´ y obsah souboru pˇri otevˇren´ı se dá pˇr´ıznakem O TRUNC ve funkci open. • podrobnosti je tˇreba hledat v manuálové stránce, napˇr. ve FreeBSD v sekci BUGS nalezneme toto: Use of truncate to extend a file is not portable.

101

Duplikace deskriptoru: dup(), dup2() int dup(int fildes ); • duplikuje deskriptor fildes na prvn´ı voln´ y deskriptor, vrát´ı nov´ y deskriptor, kter´ y odkazuje na stejné otevˇren´ı souboru. • ekvivalent fcntl(fildes, F DUPFD, 0); int dup2(int fildes, int fildes2 ); • duplikuje deskriptor fildes do deskriptoru fildes2. • ekvivalent close(fildes2); fcntl(fildes, F DUPFD, fildes2);

• prvn´ı voln´ y deskriptor se pouˇzije i u otev´ırán´ı a vytváˇren´ı soubor˚ u, viz strany 99 a 100. • duplikovan´ y a p˚ uvodn´ı deskriptor sd´ıl´ı stejné otevˇren´ı souboru a tedy i aktu´ aln´ı pozici a m´ od ˇcten´ı/z´ apis. • ekvivalent pro dup2 nen´ı zcela ekvivalentn´ı, napˇr. pokud je fildes rovn´ y fildes2, tak se neprovede close(fildes2) a dup2 rovnou vrát´ı fildes2. V´ıce viz POSIX 1003.1 (ˇc´ ast XSH, System interfaces).

102

Pˇ r´ıklad: implementace shellov´ eho pˇ resmˇ erov´ an´ı • $ program < in > out 2>> err close(0); open("in", O_RDONLY); close(1); open("out", O_WRONLY | O_CREAT | O_TRUNC, 0666); close(2); open("err", O_WRONLY | O_CREAT | O_APPEND, 0666); • $ program > out 2>&1 close(1); open("out", O_WRONLY | O_CREAT | O_TRUNC, 0666); close(2); dup(1);

• vˇsimnˇete si korespondence flagu O APPEND s >> • Dalˇs´ı pˇr´ıklad pouˇzit´ı dup uvid´ıme, aˇz se budeme zab´ yvat rourami. Prvn´ı pˇresmˇerov´ an´ı (bez stderr) je v read/redirect.c . Volán´ı execl v tomto pˇr´ıkladu nahrad´ı aktu´ aln´ı obraz bˇeˇz´ıc´ıho procesu obrazem programu pˇredaného jako prvn´ı argument. V´ıce o volán´ı execl je na stranˇe 137. • pro pochopen´ı toho jak funguje pˇresmˇerován´ı je dobré si nakreslit tabulku deskriptor˚ u v ˇcase a kam ”ukazuj´ı”. napˇr. pro druh´ y pˇr´ıklad (iniciáln´ı stav, stav po close(1) open("out", ...), koneˇcn´ y stav): +-------+ +-------+ +-------+ | 0 +-> stdin | 0 +-> stdin | 0 +-> stdin +-------+ +-------+ +-------+ | 1 +-> stdout ===> | 1 +-> "out" ===> | 1 +-> "out" +-------+ +-------+ +-------+ ^ | 2 +-> stderr | 2 +-> stderr | 2 +----/ +-------+ +-------+ +-------+ • Je potˇreba si d´ at pozor na stav deskriptor˚ u. Druh´ y pˇr´ıklad nebude fungovat, kdyˇz bude deskriptor 0 uzavˇren, protoˇze open vrát´ı deskriptor 0 (prvn´ı voln´ y) a dup vr´ at´ı chybu (pokus o duplikaci uzavˇreného deskriptoru). Moˇzné ˇreˇsen´ı: close(1); if((fd = open("out", O WRONLY | O CREAT | O TRUNC, 0666)) == 0) dup(0);

103

close(2); dup(1); if(fd == 0) close(0); nebo fd = open("out", O WRONLY | O CREAT | O TRUNC, 0666); if(fd != 1) { dup2(fd, 1); close(fd); } dup2(1, 2);

ˇ ıdic´ı funkce soubor˚ R´ u a zaˇ r´ızen´ı: fcntl(), ioctl() int fcntl(int fildes, int cmd, ...); • slouˇz´ı pro duplikaci deskriptor˚ u, nastavován´ı zámk˚ u, testován´ı a nastavov´ an´ı r˚ uzn´ ych pˇr´ıznak˚ u souboru. pˇr´ıklad: zavˇren´ı standardn´ıho vstupu pˇri spuˇstˇen´ı programu (vol´ an´ı typu exec) fcntl(0, F SETFD, FD CLOEXEC); int ioctl(int fildes, int request, ... ); • rozhran´ı pro ˇr´ıdic´ı funkce perifern´ıch zaˇr´ızen´ı • pouˇz´ıv´ a se jako univerzáln´ı rozhran´ı pro ovládán´ı zaˇr´ızen´ı, kaˇzdé zaˇr´ızen´ı definuje mnoˇzinu pˇr´ıkaz˚ u, kter´ ym rozum´ı.

• jak pozdˇeji uvid´ıme, i k socket˚ um se pˇristupuje pˇres souborové deskriptory, a je tedy moˇzné fnctl pouˇz´ıt i na nˇe, tˇreba pro nastaven´ı neblokuj´ıc´ıho socketu. V´ıce informac´ı viz strana 198. • moˇzné hodnoty cmd ve funkci fcntl: – F DUPFD . . . duplikace deskriptoru – F GETFD . . . zjiˇstˇen´ı pˇr´ıznak˚ u deskriptoru (FD CLOEXEC – uzavˇren´ı pˇri exec). FD CLOEXEC je jedin´ y flag pro deskriptory, definovan´ y v normˇe UNIX 03. – F SETFD . . . nastaven´ı pˇr´ıznak˚ u deskriptoru

104

– F GETFL . . . zjiˇstˇen´ı m´ odu ˇcten´ı/zápis a pˇr´ıznak˚ u otevˇren´ı souboru (jako u open) u otevˇren´ı souboru (O APPEND, O DSYNC, – F SETFL . . . nastaven´ı pˇr´ıznak˚ O NONBLOCK, O RSYNC, O SYNC). Nemohu nastavit pˇr´ıznaky pro RO/RW a ani pˇr´ıznaky pro vytvoˇren´ı, zkrácen´ı nebo exkluzivn´ı pˇr´ıstup k souboru. u – F GETLK, F SETLK, F SETLKW . . . nastavován´ı zámk˚ • je d˚ uleˇzité si uvˇedomit, ˇze jsou dva druhy pˇr´ıznak˚ u – pˇr´ıznak(y) pro souborov´ y deskriptor a pˇr´ıznaky pro jedno konkrétn´ı otevˇren´ı souboru – tj. pˇr´ıznaky jsou uloˇzené ve dvou r˚ uzn´ ych tabulkách. • perifern´ı zaˇr´ızen´ı podporuj´ı ˇcten´ı a zápis dat pomoc´ı read, write a mapován´ı dat do pamˇeti (mmap), veˇskeré dalˇs´ı operace se zaˇr´ızen´ım (napˇr. nastaven´ı parametr˚ u, zamˇcen´ı nebo eject) se dˇelaj´ı funkc´ı ioctl. • pˇri nastavov´ an´ı pˇr´ıznak˚ u nejdˇr´ıv vˇzdy zjistˇete, jaké byly pˇredt´ım. I kdyˇz jste si jisti, ˇze v dané chv´ıli jsou nulové a je tedy moˇzné provést fcntl(fd, uˇzete vˇedˇet, co se m˚ uˇze zmˇenit (napˇr´ıklad o pár ˇrádk˚ u v´ yˇse O APPEND), nem˚ nˇejak´ y flag pˇrid´ ate, aniˇz byste vˇedˇeli, ˇze jste ovlivnˇeni kódem dole). Tedy vˇzdy pouˇzijte napˇr´ıklad toto: flags = fcntl(fd, F_GETFL); if (fcntl(fd, F_SETFL, flags | O_APPEND) == -1) ... . . . a podobnˇe pro odebr´ an´ı flagu – je ˇspatné ˇreˇsen´ı nastavit hodnot˚ u flag˚ u na nulu, m´ısto toho je tˇreba pouˇz´ıt bitového jedniˇckového doplˇ nku pˇr´ısluˇsného flagu (flags & ~O APPEND).

105

Informace o souboru: stat() int stat(const char *path, struct stat *buf ); int fstat(int fildes, struct stat *buf ); • pro soubor zadan´ y cestou, resp. ˇc´ıslem deskriptoru, vrát´ı strukturu obsahuj´ıc´ı informace o souboru, napˇr.: – st ino . . . ˇc´ıslo i-uzlu – st dev . . . ˇc´ıslo zaˇr´ızen´ı obsahuj´ıc´ıho soubor – st uid, st gid . . . vlastn´ık a skupina souboru – st mode . . . typ souboru a jeho pˇr´ıstupová práva – st size, st blksize, st blocks . . . velikost souboru v bajtech, preferovaná velikost bloku pro I/O a poˇcet blok˚ u – st atime, st mtime, st ctime . . . ˇcasy posledn´ıho pˇr´ıstupu, modifikace souboru a modifikace i-uzlu – st nlink . . . poˇcet odkaz˚ u na soubor

• update ˇcasu posledn´ıho pˇr´ıstupu k souboru lze na bˇeˇzn´ ych file systémech vypnout pomoc´ı optionu noatime pˇr´ıkazu mount. Hodit se to m˚ uˇze pro urychlen´ı, pokud se prov´ ad´ı ˇcten´ı velkého mnoˇzstv´ı soubor˚ u a nezáleˇz´ı na ˇcasu pˇr´ıstupu na tˇechto souborech (napˇr. pˇri kompilaci). • Metadata jsou informace o souboru – tedy mód, ˇcasy pˇr´ıstupu, délka, vlastn´ık a skupina atd. Nepatˇr´ı mezi nˇe skuteˇcná data souboru, a ani jméno, které nen´ı uloˇzeno v r´ amci daného souboru, ale v adresáˇri ˇci v adresáˇr´ıch. • Metadata je moˇzné pˇreˇc´ıst, i kdyˇz proces nemá práva pro ˇcten´ı obsahu souboru. • Touto funkc´ı nez´ısk´ am flagy deskriptoru ani flagy z pole tabulky otevˇren´ ych soubor˚ u v systému, zde jde o informace ohlednˇe souboru uloˇzeného na pamˇet’ovém médiu. • Co se stane kdyˇz se zavol´ a fstat na deskriptory 0,1,2 ? (pˇredpokládáme ˇze nejsou pˇresmˇerované z normáln´ıho stavu) • st ctime nen´ı ˇcas vytvoˇren´ı souboru (creation time), ale ˇcas zmˇeny indexového uzlu (change time) • Norma nespecifikuje poˇrad´ı poloˇzek ve struktuˇre ani nezakazuje pˇridat dalˇs´ı. • Pˇr´ıklad: stat/stat.c

106

Informace o souboru (2) • pro typ souboru jsou v <sys/stat.h> definovány konstanty S_IFMT (maska pro typ), S_IFBLK (blokov´ y speciáln´ı), S_IFCHR (znakov´ y speci´ aln´ı), S_IFIFO (FIFO), S_IFREG (obyˇcejn´ y), S_IFDIR (adres´ aˇr), S_IFLNK (symlink). • typ lze testovat pomoc´ı maker S_ISBLK(m), S_ISCHR(m), S_ISFIFO(m), S_ISREG(m), S_ISDIR(m), S_ISLNK(m). • konstanty pro pˇr´ıstupová práva: S_IRUSR (ˇcten´ı pro vlastn´ıka), S_IWGRP (z´ apis pro skupinu), atd. int lstat(const char *path, struct stat *buf ); • kdyˇz je zkouman´ y soubor symlink, stat() vrát´ı informace o souboru, na kter´ y ukazuje. Tato funkce vrac´ı informace o symlinku.

• typ a pr´ ava souboru jsou uloˇzena spoleˇcnˇe v st_mode, proto existuj´ı zmiˇ novan´ a makra. • S IFMT specifikuje tu ˇc´ ast bit˚ u, které jsou vˇenované typu souboru, makra pro jednotlivé typy pak nejsou masky, ale hodnoty, takˇze test na typ souboru je nutné udˇelat takto: (st mode & S IFMT == S IFREG). Vˇsechna makra jsou v normˇe, takˇze jejich pouˇz´ıván´ım zaruˇc´ıme pˇrenositeln´ y kód. • Pˇr´ıklad: stat/filetype.c

107

Nastaven´ı ˇ cas˚ u souboru int utime(const char *path, const struct utimbuf *times ); • nastav´ı ˇcas posledn´ı modifikace souboru a ˇcas posledn´ıho pˇr´ıstupu k souboru. • nelze zmˇenit ˇcas posledn´ı modifikace i-uzlu. • volaj´ıc´ı proces mus´ı m´ıt právo zápisu pro soubor.

• Tuto funkci pouˇz´ıvaj´ı hlavnˇe kop´ırovac´ı a archivaˇcn´ı programy, aby zajistily stejné ˇcasy kopie a origin´ alu (napˇr. tar nebo rsync). • Shellové rozhran´ı pro funkci utime pˇredstavuje pˇr´ıkaz touch. Mˇenit takto ˇcas modifikace i-uzlu ale nelze.

108

Test pˇ r´ıstupov´ ych pr´ av: access() int access(const char *path, int amode ); • otestuje, zda volaj´ıc´ı proces má k souboru path práva daná OR-kombinac´ı konstant v amode: – R_OK . . . test pr´ ava na ˇcten´ı – W_OK . . . test pr´ ava na zápis – X_OK . . . test pr´ ava na spuˇstˇen´ı – F_OK . . . test existence souboru • na rozd´ıl od stat(), v´ ysledek závis´ı na RUID a RGID procesu • toto vol´ an´ı se ned´ a pouˇz´ıt bezpeˇcnˇe, proto ho nikdy nepouˇz´ıvejte procesu

• Vol´ an´ı access aplikuje mechanismus testován´ı pˇr´ıstupov´ ych práv k zadanému souboru pro volaj´ıc´ı proces a vrát´ı v´ ysledek. • Funkce access vol´ an´ı byla pro setuid proces, aby si mohl ovˇeˇrit, zda uˇzivatel bˇeˇz´ıc´ı dan´ y setuid proces by mˇel za normáln´ıch okolnost´ı k pˇr´ısluˇsnému souboru pˇr´ıstup. Z toho vypl´ yv´ a, ˇze toto volán´ı je security hole – mezi testem a n´ aslednou akc´ı se soubor m˚ uˇze zmˇenit tˇreba tak, ˇze p˚ uvodn´ı (m˚ uj) soubor smaˇzu a vytvoˇr´ım symbolick´ y link se stejn´ ym jménem na soubor, ke kterému bych jinak nemˇel pˇr´ıstup. Toto proces nem˚ uˇze nikdy oˇsetˇrit, takˇze vesele zmodifikuje soubor, kter´ y bych jako uˇzivatel nikdy nemohl zmˇenit. Spr´ avn´ ym ˇreˇsen´ım je vr´ atit se zpátky k reáln´ ym UID/GID a pˇr´ıstup rovnou vyzkouˇset. Pokud napˇr´ıklad dan´ y soubor otevˇreme, uˇz nám ho nikdo pod rukama “nevymˇen´ı”.

109

Nastaven´ı pˇ r´ıstupov´ ych pr´ av int chmod(const char *path, mode t mode ); • zmˇen´ı pˇr´ıstupov´ a pr´ ava souboru path na hodnotu mode. • tuto sluˇzbu m˚ uˇze volat pouze vlastn´ık souboru nebo superuˇzivatel (root). int chown(const char *path, uid t owner, gid t group ); • zmˇen´ı vlastn´ıka a skupinu souboru path. Hodnota -1 znamená zachovat vlastn´ıka, resp. skupinu. • mˇenit vlastn´ıka m˚ uˇze jen superuˇzivatel, aby uˇzivatelé nemohli obch´ azet nastavené quoty t´ım, ˇze své soubory pˇredaj´ı nˇekomu jinému. • bˇeˇzn´ y uˇzivatel m˚ uˇze mˇenit skupinu sv´ ych soubor˚ u a mus´ı pˇritom patˇrit do c´ılové skupiny.

• parametr mode zde samozˇrejmˇe neobsahuje typ souboru, jako tomu je napˇr´ıklad u vol´ an´ı stat. Hodnoty mode viz chmod(2). • pokud nejsem vlastn´ık, nemohu celkem logicky zmˇenit mód ani u souboru s nastaven´ ym pˇr´ıstupem rw-rw-rw• v nˇekter´ ych implementac´ıch m˚ uˇze vlastn´ık souboru pˇredat vlastnictv´ı nˇekomu jinému, napˇr. v IRIXu je chován´ı chown nastavitelné jako parametr j´ adra. • nen´ı bˇeˇzné volat funkci chmod z uˇzivatelsk´ ych aplikac´ı, na to se pouˇz´ıvaj´ı flagy u vol´ an´ı open, hlavn´ı pouˇzit´ı je v aplikaci chmod(1)

110

Manipulace se jm´ eny soubor˚ u int link(const char *path1, const char *path2 ); • vytvoˇr´ı nov´ y odkaz (poloˇzku adresáˇre) path2 na soubor path1. Funguje pouze v r´ amci jednoho svazku. int unlink(const char *path ); • zruˇs´ı odkaz na soubor. Po zruˇsen´ı posledn´ıho odkazu na soubor a uzavˇren´ı souboru vˇsemi procesy je soubor smazán. int rename(const char *old, const char *new ); • zmˇen´ı jméno souboru (pˇresnˇe odkazu na soubor) z old na new. Funguje pouze v r´ amci jednoho svazku.

• opˇet zd˚ urazˇ nuji, ˇze unix nem´ a vol´ an´ı typu delete na soubory. Podrobnˇeji viz strana 73. • vol´ an´ı link vytv´ aˇr´ı hardlinky, tj. zobrazen´ı ze jména souboru na ˇc´ıslo i-uzlu. ˇ ısla i-uzl˚ C´ u jsou jednoznaˇcná pouze v rámci svazku, proto pro linky mezi filesystémy je nutné pouˇz´ıt symlinky. • parametr path2 nesm´ı existovat, tedy nelze takto pˇrejmenovávat • unlink nefunguje na adres´ aˇre • shellov´ y pˇr´ıkaz mv pouˇz´ıv´ a rename pro pˇresuny v rámci jednoho svazku. Pˇresun souboru mezi filesystémy vyˇzaduje nejprve soubor zkop´ırovat a pak smazat origin´ al vol´ an´ım unlink. • rename funguje nad symlinky, ne nad soubory, na které symlink ukazuje • existuje i vol´ an´ı remove, viz strana 120.

111

Symbolick´ e linky int symlink(const char *path1, const char *path2 ); • vytvoˇr´ı symbolick´ y link path2 → path1. • c´ıl symbolického linku m˚ uˇze b´ yt i na jiném svazku, popˇr´ıpadˇe nemus´ı v˚ ubec existovat. int readlink(const char *path, char *buf, size t bufsize ); • do buf d´ a max. bufsize znak˚ u z cesty, na kterou ukazuje symlink path. • vr´ at´ı poˇcet znak˚ u uloˇzen´ ych do buf. • obsah buf nen´ı zakonˇcen nulou (znakem ’\0’)!

• Shellov´ y pˇr´ıkaz ln vol´ a symlink nebo link, podle toho, jestli je pouˇzit pˇrep´ınaˇc -s nebo ne. • Smaz´ an´ı hardlinku nesmaˇze soubor, pokud na nˇej vede jeˇstˇe jin´ y hardlink. Naopak soubor (poloˇzku adresáˇre i data) je moˇzné smazat, i kdyˇz na nˇej ukazuj´ı nˇejaké symlinky. • readlink je pouˇziteln´ y v situaci, pokud chci smazat soubor, na kter´ y dan´ y symlink ukazuje • bufsize se typicky d´ av´ a o 1 menˇs´ı neˇz velikost bufferu, to pro ukonˇcen´ı znakem ’\0’

112

Manipulace s adres´ aˇ ri int mkdir(const char *path, mode t mode ); • vytvoˇr´ı nov´ y pr´ azdn´ y adresáˇr, kter´ y bude obsahovat pouze poloˇzky ’.’ a ’..’ int rmdir(const char *path ); • smaˇze adres´ aˇr path. Adresáˇr mus´ı b´ yt prázdn´ y. DIR *opendir(const char *dirname ); struct dirent *readdir(DIR *dirp ); int closedir(DIR *dirp ); • slouˇz´ı k sekvenˇcn´ımu procházen´ı adresáˇr˚ u. • struktura dirent obsahuje poloˇzky – d_ino . . . ˇc´ıslo i-uzlu – d_name . . . jméno souboru

• Poloˇzky adres´ aˇre nejsou nijak uspoˇrádány, readdir je m˚ uˇze vracet v libovolném poˇrad´ı. V pˇr´ıpadˇe chyby se vrac´ı NULL jako pˇredt´ım a errno je nastaveno. Konec adres´ aˇre se signalizuje t´ım, ˇze readdir vrát´ı NULL a errno nen´ı zmˇenˇeno. • readdir je stavov´ a funkce. Pro vrácen´ı se na zaˇcátek je moˇzné pouˇz´ıt funkci rewinddir. Pokud tuto funkci voláte z v´ıce vláken je nutné pouˇz´ıvat reentrantn´ı readdir r, protoˇze struktura dirent je statická. • V nˇekter´ ych implementac´ıch (napˇr. FreeBSD) lze adresáˇr otevˇr´ıt pro ˇcten´ı (ne pro z´ apis) jako norm´ aln´ı soubor a ˇc´ıst ho pomoc´ı read, ale je tˇreba znát jeho vnitˇrn´ı organizaci. Proto je readdir pro zpracován´ı obsahu adresáˇre lepˇs´ı neˇz read, kter´ y vrac´ı raw data adresáˇre. Kromˇe toho, norma nevyˇzaduje, aby adres´ aˇr bylo moˇzné ˇc´ıst funkc´ı read, Linux to napˇr´ıklad nedovol´ı. • d ino nen´ı moc uˇziteˇcné, protoˇze v pˇr´ıpadˇe, kdy dan´ y adresáˇr je mount point, tak ukazuje na adres´ aˇr, na kter´ y je dalˇs´ı filesystém namontován, ne na koˇren namontovaného filesystému • Nˇekteré systémy maj´ı ve struktuˇre dirent poloˇzku d type. Ta m˚ uˇze nab´ yvat hodnot DT REG, DT DIR, DT FIFO atd., viz manuálová stránka pro dirent. Byla to vˇec specifick´ a pro BSD a následnˇe pˇrevzatá i jin´ ymi systémy, napˇr´ıklad Linuxem. Nen´ı to souˇca´st´ı normy a tedy to nen´ı pˇ renositeln´ e. Pˇrenositeln´ y zp˚ usob je na kaˇzdou poloˇzku zavolat stat. • rmdir nefunguje na nepr´ azdn´ y adresáˇr, mus´ıte sami smazat jeho obsah pˇred smaz´ an´ım adres´ aˇre. Nˇekdy lze v kódu nalézt zoufalé pokusy typu system("rm

113

-r xxx") coˇz m´ a svoje nev´ yhody (napˇr. závislost programu na shellu. Dále pozor na sanitizaci promˇenn´ ych prostˇred´ı a jména adresáˇre). • Norma specifikuje i vol´ an´ı remove, které se chová jako unlink pro regulárn´ı soubory, a jako rmdir pro adresáˇre.

Pˇ r´ıklad: proch´ azen´ı adres´ aˇ re int main(int argc, char *argv[]) { int i; DIR *d; struct dirent *de; for(i = 1; i < argc; i++) { d = opendir(argv[i]); while(de = readdir(d)) printf("%s\n", de->d_name); closedir(d); } return (0); }

• pˇr´ıkaz ls je zaloˇzen na takovéto smyˇcce, nav´ıc provád´ı napˇr. tˇr´ıdˇen´ı jmen soubor˚ u a zjiˇst’ov´ an´ı dalˇs´ıch informac´ı pomoc´ı stat. • konec adres´ aˇre se pozn´ a tak, ˇze readdir vrát´ı NULL. To vˇsak vrát´ı i v pˇr´ıpadˇe, pokud nastala chyba. V takovém pˇr´ıpadˇe je kód chyby v promˇenné errno, v pˇr´ıpadˇe prvn´ım je errno nezmˇenˇena. Proto by errno mˇelo b´ yt vˇzdy nastavené na nulu pˇred vol´ an´ım readdir. V pˇr´ıkladu tomu tak nen´ı, protoˇze z d˚ uvodu m´ alo m´ısta nekontrolujeme errno v˚ ubec. • pˇr´ıklad: readdir/readdir.c

114

Aktu´ aln´ı adres´ aˇ r procesu • kaˇzd´ y proces m´ a sv˚ uj aktuáln´ı (pracovn´ı) adresáˇr, v˚ uˇci kterému jsou ud´ av´ any relativn´ı cesty k soubor˚ um. Poˇcáteˇcn´ı nastaven´ı pracovn´ıho adres´ aˇre se dˇed´ı od otce pˇri vzniku procesu. int chdir(const char *path ); int fchdir(int fildes ); • nastav´ı nov´ y pracovn´ı adresáˇr procesu. char *getcwd(char *buf, size t size ); • uloˇz´ı absolutn´ı cestu k aktuáln´ımu adresáˇri do pole buf, jeho délka (size) mus´ı b´ yt aspoˇ n o 1 vˇetˇs´ı neˇz délka cesty.

• funkci fchdir se pˇred´ av´ a deskriptor z´ıskan´ y volán´ım open na adresáˇr. • funkce getcwd m˚ uˇze vr´ atit jinou cestu neˇz tu, po které jsme se do aktuáln´ıho adres´ aˇre dostali, jesliˇze ˇc´ ast cesty v chdir byl symlink nebo doˇslo k pˇresunu (pˇrejmenov´ an´ı) nˇekterého adresáˇre na cestˇe od koˇrene. U souˇcasn´ ych unix˚ u by se to ale uˇz st´ at nemˇelo. • na vˇetˇsinˇe modern´ıch unixov´ ych systém˚ u existuje funkce chroot, která umoˇzn ˇuje zmˇenit koˇrenov´ y adres´ aˇr volaj´ıc´ıho procesu na dan´ y adresáˇr. Je ˇcasto pouˇz´ıvan´ a v implementac´ı server˚ u k omezen´ı pˇr´ıstupu pouze na dan´ y podstrom file systému (napˇr. FTP servery). Pokud se pouˇz´ıvá pro zapezpeˇcen´ı, vyˇzaduje to zvl´ aˇstn´ı opatrnost, protoˇze existuj´ı cesty jak se dostat do p˚ uvodn´ıho stromu. Pokud je nutné z chroot prostˇred´ı spouˇstˇet programy, nastávaj´ı dalˇs´ı komplikace s nutnost´ı replikace kritick´ ych systémov´ ych soubor˚ u do chroot prostˇred´ı (pokud nen´ı program upraven aby mˇel vˇse zabudované v sobˇe). Tato funkce nen´ı souˇcást´ı aktuáln´ı verze standardu (POSIX 1003.12008). – dalˇs´ı, mnohem obecnˇejˇs´ı, zp˚ usoby izolace proces˚ u se daj´ı nalézt v unixov´ ych systémech (jails v FreeBSD, zones v Solarisu, sandboxing v Mac OS X). Zpravidla se velmi liˇs´ı t´ım jaké hranice dokáˇz´ı vytyˇcit, k ˇcemu jsou urˇceny, zp˚ usobem administrace, . . . .

115

Obsah • u ´vod, v´ yvoj UNIXu a C, programátorské nástroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupov´ a pr´ ava, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇ stˇ en´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vláken • ??? - bude definov´ ano pozdˇeji, podle toho kolik zbyde ˇcasu

116

Pamˇ et’ procesu v uˇ zivatelsk´ em reˇ zimu text data bss

nelze adresovat uˇziv. programem

{

zásobn´ık oblast user

                adresovatelné  uˇziv. programem               

• kaˇzd´ y systém m˚ uˇze pouˇz´ıvat zcela jiné rozdˇelen´ı adresového prostoru procesu (a typicky tomu tak je). Konkrétn´ı pˇr´ıklad je na následuj´ıc´ım slajdu, a zobrazuje i sekce pro mmap a hromadu (heap). • text . . . k´ od programu • data . . . inicializované promˇenné • sekce text a data jsou uloˇzeny ve spustitelném souboru • bss . . . neinicializované promˇenné (bss pocház´ı z assembleru IBM 7090 a znamen´ a ,,block started by symbol”). Za bˇehu programu tvoˇr´ı sekce data, bss a heap (nen´ı na obr´ azku) dohromady datové segmenty procesu. Velikost hromady lze mˇenit pomoc´ı systémov´ ych volán´ı brk a sbrk. • pozn´ amka – neinicializované promˇenné jsou statické promˇenné, které (pˇrekvapivˇe) nejsou inicializované – tj. globáln´ı promˇenné nebo promˇenné definované jako static ve funkc´ıch i mimo funkce. Jak v´ıte z pˇrednáˇsek o jazyku C, vˇsechny tyto promˇenné jsou pˇri startu programu automaticky inicializované nulami. Proto nen´ı nutné m´ıt jejich hodnotu v binárce. Jakmile ale nˇejakou z takov´ ych promˇenn´ ych inicializujete, bude jiˇz souˇcást´ı datového segmentu programu na disku. • (uˇzivatelský) z´ asobn´ık . . . lokáln´ı nestatické promˇenné, parametry funkc´ı (na urˇcit´ ych architektur´ ach v dan´ ych modech - 32-bit x86), návratové adresy. Kaˇzd´ y proces m´ a dva z´ asobn´ıky, jeden pro uˇzivatelsk´ y reˇzim a jeden pro reˇzim j´ adra. Uˇzivatelsk´ y z´ asobn´ık procesu automaticky roste podle potˇreby

117

(neplat´ı, pokud se pouˇz´ıvaj´ı vlákna, tam má nav´ıc kaˇzdé vlákno zásobn´ık sv˚ uj). • oblast user (u-area) . . . obsahuje informace o procesu pouˇz´ıvané jádrem, které nejsou potˇrebné, kdyˇz je proces odloˇzen na disku (poˇcet otevˇren´ ych soubor˚ u, nastaven´ı oˇsetˇren´ı sign´ al˚ u, poˇcet segment˚ u sd´ılené pamˇeti, argumenty programu, promˇenné prostˇred´ı, aktuáln´ı adresáˇr, atd.). Tato oblast je pˇr´ıstupná pouze pro j´ adro, které vˇzdy vid´ı právˇe jednu u-oblast patˇr´ıc´ı právˇe bˇeˇz´ıc´ımu procesu. Dalˇs´ı informace o procesu, které jádro m˚ uˇze potˇrebovat i pro jin´ y neˇz pr´ avˇe bˇeˇz´ıc´ı proces, nebo i kdyˇz je proces odloˇzen, jsou ve struktuˇre proc. Struktury proc pro vˇsechny procesy jsou stále rezidentn´ı v pamˇeti a viditelné v reˇzimu j´ adra.

Pˇ r´ıklad: Solaris 11 x86 32-bit

• z obr´ azku lze vyˇc´ıst nˇekolik dalˇs´ıch vˇec´ı: – maxim´ aln´ı velikost kernelu pro Solaris 11 x86 32-bit je 256 megabajt˚ u – mezi namapov´ an´ım kernelu a pamˇet´ı vyhrazenou pro mmap je volné m´ısto – z´ asobn´ık roste smˇerem k niˇzˇs´ım adresám a jeho velikost je omezena na 128 megabajt˚ u • heap je ˇc´ ast pamˇeti, kterou si proces m˚ uˇze zvˇetˇsovat pomoc´ı volán´ı brk a sbrk, a je ˇcasto pouˇz´ıvan´ a funkc´ı malloc. Funguje to tak, ˇze malloc si postupnˇe zvˇetˇsuje hromadu podle potˇreby, a pˇriˇrazenou pamˇet’ internˇe spravuje a pˇridˇeluje ji procesu po ˇc´ astech. Kdyˇz tedy voláte free, neznamená to, ˇze vrac´ıte pamˇet’ systému, ale pouze intern´ımu alokátoru.

118

• oblast pro mmap se pouˇz´ıv´ a pro mapován´ı soubor˚ u, tedy i sd´ılen´ ych knihoven. Nˇekteré alok´ atory pouˇz´ıvaj´ı internˇe i tuto pamˇet’, napˇr´ıklad pro vˇetˇs´ı kusy pamˇeti ˇz´ adané najednou. Je moˇzné exkluzivnˇe pouˇz´ıvat pouze mmap, pro aplikaci je to zcela transparentn´ı. Pˇri pouˇzit´ı mmap je moˇzné pamˇet’ systému vracet (vol´ an´ım munmap), na rozd´ıl od implementace pomoc´ı brk/sbrk. • obr´ azek byl pˇrevzat z [McDougall-Mauro], a nen´ı na nˇem oblast pro neinicializované promˇenné. Pokud si ale na tomto systému necháte vypsat adresu jedné z nich, zjist´ıte, ˇze inicializované i neinicializované promˇenné sd´ıl´ı spoleˇcn´ y datov´ y segment, na obrázku oznaˇcen´ y jako ,,executable – DATA”. Pˇr´ıklad: pmap/proc-addr-space.c • mapov´ an´ı kernelu nen´ı nutné, napˇr´ıklad u Solarisu na amd64 architektuˇre (tj. 64-bit) uˇz kernel do uˇzivatelského prostoru procesu mapován nen´ı. • brk ani sbrk nejsou souˇc´ ast´ı normy, pˇrenositelné aplikace by proto mˇely pouˇz´ıvat, pokud podobnou funkcionalitu potˇrebuj´ı, volán´ı mmap, viz strana 146.

Pamˇ et’ procesu v reˇ zimu j´ adra text jádra data a bss jádra (tabulky, promˇenné, apod.) struktura user beˇz´ıc´ıho procesu

extern struct user u; zásobn´ık jádra

• proces se dostane do reˇzimu jádra bud’ pˇr´ıchodem pˇreruˇsen´ı vyvolaného procesorem (v´ ypadek str´ anky, neznámá instrukce,...), ˇcasovaˇcem (v pravideln´ ych intervalech je potˇreba aktivovat plánovaˇc proces˚ u), perifern´ım zaˇr´ızen´ım, nebo instrukc´ı synchronn´ıho pˇreruˇsen´ı (standardn´ı knihovna takto pˇredává ˇr´ızen´ı j´ adru, aby obslouˇzilo systémové vol´ an´ı). • v pamˇeti je pouze jedna kopie kódu a dat jádra, sd´ılená vˇsemi procesy. Kód j´ adra je vˇzdy cel´ y rezidentn´ı v pamˇeti, nen´ı odkládán na disk. 119

• text j´ adra . . . k´ od j´ adra operaˇcn´ıho systému, zaveden´ y pˇri startu systému a rezidentn´ı v pamˇeti po celou dobu bˇehu systému. Nˇekteré implementace umoˇzn ˇuj´ı pˇrid´ avat funkˇcn´ı moduly do jádra za bˇehu (napˇr. pˇri pˇridán´ı nového zaˇr´ızen´ı se do j´ adra dynamicky pˇridá nov´ y ovladaˇc), nen´ı proto tˇreba kv˚ uli kaˇzdé zmˇenˇe regenerovat j´ adro a restartovat systém. • data a bss j´ adra . . . datové struktury pouˇz´ıvané jádrem, souˇcást´ı je i u-oblast pr´ avˇe bˇeˇz´ıc´ıho procesu. • z´ asobn´ık j´ adra . . . samostatn´ y pro kaˇzd´ y proces, je prázdn´ y, jestliˇze je proces v uˇzivatelském reˇzimu (a tedy pouˇz´ıvá uˇzivatelsk´ y zásobn´ık).

Pamˇ et’ov´ e segmenty procesu a segs struct as

read only shared

s as s prev

text

s next

read/write private

data

read/write private

zásobn´ık

read/write shared

sd´ılená pamˇet’

struct proc

• kaˇzd´ y proces m´ a tˇri z´ akladn´ı segmenty (pamˇet’ové segmenty, nemluv´ıme o hardwarov´ ych segmentech): – text – data – z´ asobn´ık • sekce pro inicializované i neinicializované promˇenné a hromada jsou brány dohromady jako data • d´ ale lze do adresového prostoru pˇripojit segmenty sd´ılené pamˇeti (shmat) nebo soubory (mmap). • text je sd´ılen vˇsemi procesy, které provád´ı stejn´ y kód. Datov´ y segment a z´ asobn´ık jsou priv´ atn´ı pro kaˇzd´ y proces. 120

• z´ akladn´ım rysem této architektury je tzv. memory object, coˇz je abstrakce mapov´ an´ı mezi kusem pamˇeti a m´ıstem, kde jsou data normálnˇe uloˇzena (tzv. backing store nebo data object). Takové m´ısto uloˇzen´ı m˚ uˇze b´ yt napˇr´ıklad swap nebo soubor. Adresov´ y prostor procesu je pak mnoˇzina mapován´ı na r˚ uzné datové objekty. Existuje i anonymn´ı objekt, kter´ y nemá m´ısto trvalého uloˇzen´ı (pouˇz´ıv´ a se napˇr´ıklad pro zásobn´ık). Fyzická pamˇet’ pak slouˇz´ı jako cache pro data tˇechto namapovan´ ych datov´ ych objekt˚ u. • tato zde velmi hrubˇe popsaná architektura se naz´ yvá VM (od Virtual Memory), a objevila se v SunOS 4.0. Na této architektuˇre je zaloˇzena architektura viru´ aln´ı pamˇeti v SVR4. V´ıce informac´ı viz [Vahalia], p˚ uvodn´ı ˇclánek z roku 1987 pˇredstavuj´ıc´ı tuto architekturu: Gingell, R. A., Moran J. P., Shannon, W. A. – Virtual Memory Architecture in SunOS nebo pˇrednáˇska o operaˇcn´ıch systémech na MFF (NSWI004 - Operaˇcn´ı systémy). • z jak´ ych segment˚ u se skl´ ad´ a pamˇet’ov´ y prostor konkrétn´ıho procesu lze zjistit pomoc´ı pˇr´ıkazu pmap(1) (na Solarisu, na NetBSD a v nˇekter´ ych Linuxov´ ych distribuc´ıch) nebo procmap(1) (v OpenBSD) nebo vmmap(1) v Mac OS X.

Virtu´ aln´ı pamˇ et’ pamˇet’ procesu 1 000 111

111 000 000 111 000 111 000 111 111 000 000 111 000 111

reálná pamˇet’

pamˇet’ procesu 3


111 000 000 111 000 111 000 111 000 111

111 000 000 111 000 111 000 111

1 0 00 11 0 1 00 11 0 1 00 11 0 1 00 11 0 1 00 11 0 1 00 011 1 00 11

11 00 00 11 00 11 00 11 00 11 00 11 00 11


1111111 0000000 0000000 1111111 1111111 0000000 111 000 000 111 000 111 000 111

1 0 0 1 0 1 0 1 0 1 0 1 0 1

• kaˇzd´ y proces vid´ı sv˚ uj adresov´ y prostor jako souvisl´ y interval (virtuáln´ıch) adres od nuly po nˇejakou maximáln´ı hodnotu. Pˇr´ıstupné jsou pouze ty adresy, na kter´ ych je namapov´ an nˇekter´ y segment procesu (to je právˇe to mapován´ı, o kterém se mluv´ı na pˇredchoz´ım slajdu). • j´ adro d´ ale rozdˇeluje pamˇet’ procesu na stránky. Kaˇzdá stránka má své um´ıstˇen´ı v r´ amci fyzické pamˇeti. Toto um´ıstˇen´ı je dáno stránkovac´ımi tabulkami

121

j´ adra a str´ anky mohou b´ yt v rámc´ıch libovolnˇe prom´ıchány v˚ uˇci jejich poˇrad´ı ve virtu´ aln´ı adresovém prostoru. • pokud nen´ı str´ anka pr´ avˇe pouˇz´ıvána, m˚ uˇze b´ yt také odloˇzena na disk. • pamˇet’ov´ y manager j´ adra zajiˇst’uje mapován´ı mezi virtuáln´ımi adresami pouˇz´ıvan´ ymi k´ odem uˇzivatelsk´ ych proces˚ u i jádra na fyzické adresy a naˇcten´ı odloˇzen´ ych str´ anek z disku pˇri v´ ypadku stránky.

Implementace virtu´ aln´ı pamˇ eti • procesy v UNIXu pouˇz´ıvaj´ı k pˇr´ıstupu do pamˇeti virtuáln´ı adresy, které na fyzické adresy pˇrevád´ı hardware ve spolupráci s j´ adrem systému. • pˇri nedostatku volné pamˇeti se odkládaj´ı nepouˇz´ıvané u ´seky pamˇeti do odkl´ adac´ı oblasti (swap) na disk. • pˇred verz´ı SVR2 se procesem swapper (nyn´ı sched) odkládaly celé procesy. • od verze SVR2 se pouˇz´ıvá stránkován´ı na ˇzádost (demand paging) a copy-on-write. Stránky se alokuj´ı aˇz pˇri prvn´ım pouˇzit´ı a priv´ atn´ı str´ anky se kop´ıruj´ı pˇri prvn´ı modifikaci. Uvolˇ nov´ an´ı a odkl´ ad´ an´ı jednotliv´ ych stránek provád´ı proces pageout, odkl´ ad´ an´ı cel´ ych proces˚ u nastupuje aˇz pˇri kritickém nedostatku pamˇeti.

pˇ reklad adres: pˇr´ıstup na neplatnou adresu nebo pokus o zápis do pamˇeti pouze pro ˇcten´ı vyvol´ a sign´ al SIGSEGV. swap: odkl´ adac´ı prostor se vytv´ aˇr´ı na samostatném odd´ılu disku, od SVR4 m˚ uˇze b´ yt i v souboru. swapper: proces swapper se snaˇz´ı odloˇzit na disk nˇejak´ y proces, kter´ y nen´ı zamˇcen v pamˇeti, a na uvolnˇené m´ısto zavést dˇr´ıve odloˇzen´ y proces. demand paging: pˇri ˇz´ adosti procesu o pamˇet’ se pouze uprav´ı tabulka stránek. Prvn´ı instrukce adresuj´ıc´ı obsah stránky vyvolá v´ yjimku. Jádro ji oˇsetˇr´ı t´ım, ˇze alokuje str´ anku. copy-on-write: v´ıce proces˚ u m˚ uˇze sd´ılet zapisovatelnou fyzickou stránku, která je ale logicky priv´ atn´ı pro kaˇzd´ y proces (tato situace nastane napˇr. po vytvoˇren´ı procesu vol´ an´ım fork). Dokud procesy z pamˇeti pouze ˇctou, pˇristupuj´ı ke sd´ılené str´ ance. Pokud se proces pokus´ı obsah stránky zmˇenit, vyvolá v´ yjimku. J´ adro zkop´ıruje str´ anku, pˇridˇel´ı procesu kopii, která uˇz je privátn´ı a proces ji m˚ uˇze d´ ale libovolnˇe mˇenit. Ostatn´ı procesy pouˇz´ıvaj´ı stále nezmˇenˇenou p˚ uvodn´ı str´ anku. 122

str´ anky k odloˇzen´ı se hledaj´ı algoritmem NRU (not recently used): kaˇzdá stránka m´ a pˇr´ıznaky referenced a modified, na zaˇcátku vynulované. Pˇri prvn´ım pˇr´ıstupu se nastav´ı referenced, pˇri zmˇenˇe modified. Oba pˇr´ıznaky se periodicky nuluj´ı. Pˇrednostnˇe se uvolˇ nuj´ı stránky, které nejsou modifikované ani pouˇzité. Str´ anky k´ odu programu a mapovan´ ych soubor˚ u se neukládaj´ı do odkl´ adac´ıho prostoru, ale obnovuj´ı se z pˇr´ısluˇsného souboru.

Stavy procesu bˇeˇz´ı v uˇziv. reˇzimu

vznik

*

pˇreruˇsen´ı

návrat

zánik

†

wait

exit kill

mátoha (zombie)

preempce pˇripraven v pamˇeti odloˇzen´ı

bˇeˇz´ı v reˇzimu jádra pˇridˇelen´ı procesoru

zaveden´ı

pˇripraven na disku

probuzen´ı

probuzen´ı

uspán´ı sp´ı v pamˇeti odloˇzen´ı sp´ı na disku

• po ukonˇcen´ı procesu vol´ an´ım exit nebo v reakci na signál pˇrecház´ı proces do stavu m´ atoha (zombie), protoˇze jádro si mus´ı pamatovat k ˇc´ıslu procesu jeho n´ avratovou hodnotu. Cel´ a pamˇet’ procesu je uvolnˇena, zb´ yvá pouze struktura proc. Proces lze definitivnˇe zruˇsit, aˇz kdyˇz se jeho rodiˇc zeptá na návratovou hodnotu vol´ an´ım typu wait. Kdyˇz nebude p˚ uvodn´ı rodiˇc k dispozici, provede vol´ an´ı wait proces init, kter´ y pˇrevzal rodiˇcovst´ı. • v dneˇsn´ıch UNIXech se obvykle do odkládac´ı oblasti na disku (swap area) neodkl´ adaj´ı celé procesy, ale jednotlivé stránky pamˇeti. • proces je usp´ an, kdyˇz o to s´ am poˇzádá, napˇr. zaˇcne ˇcekat na dokonˇcen´ı perifern´ı operace. Preempce je naopak nedobrovolné odebrán´ı procesoru plánovaˇcem.

123

Pl´ anov´ an´ı proces˚ u • preemptivn´ı pl´ anov´ an´ı – jestliˇze se proces nevzdá procesoru (neusp´ı se ˇcek´ an´ım na nˇejakou událost), je mu odebrán procesor po uplynut´ı ˇcasového kvanta. • procesy jsou zaˇrazeny do front podle priority, procesor je pˇridˇelen vˇzdy prvn´ımu pˇripravenému procesu z fronty, která m´ a nejvyˇsˇs´ı prioritu. • v SVR4 byly zavedeny prioritn´ı tˇr´ıdy a podpora proces˚ u re´ alného ˇcasu (real-time) s garantovanou maximáln´ı dobou odezvy. • na rozd´ıl od pˇredchoz´ıch verz´ı znamená v SVR4 vyˇsˇs´ı ˇc´ıslo vyˇsˇs´ı prioritu.

• z´ akladem preemptivn´ıho pl´ anov´ an´ı jsou pravideln´ a pˇ reruˇ sen´ı od ˇ casovaˇ ce, kter´ a odeberou procesor bˇeˇz´ıc´ımu procesu a pˇredaj´ı ˇr´ızen´ı jádru (aktivuje se pl´ anovaˇc proces˚ u). • jin´ a varianta je nepreemptivn´ı (kooperativn´ı) plánován´ı, kdy proces bˇeˇz´ı, dokud se s´ am nevzd´ a procesoru, tj. dokud nezavolá takovou systémovou funkci, kter´ a pˇrepne kontext na jin´ y proces. Nev´ yhodou kooperativn´ıho plánován´ı je, ˇze jeden proces m˚ uˇze st´ ale blokovat procesor a ostatn´ı procesy se nikdy nedostanou na ˇradu. • UNIX pouˇz´ıv´ a pro uˇzivatelské procesy pouze preemptivn´ı plánován´ı. • tradiˇcn´ı UNIXové j´ adro funguje kooperativn´ım zp˚ usobem, tj. proces bˇeˇz´ıc´ı v reˇzimu j´ adra nen´ı pˇrepl´ anován, dokud se sám nevzdá procesoru. J´ adra modern´ıch UNIX˚ u jsou jiˇ z preemtivn´ı – je to hlavnˇe kv˚ uli real-time systém˚ um; tam je potˇreba m´ıt moˇznost bˇeˇz´ıc´ı proces zbavit procesoru okamˇzitˇe, neˇcekat na to, aˇz se vrát´ı z reˇzimu jádra nebo se sám usp´ı. Pozor na at’ to nepletete – UNIX byl od samého zaˇcátku preemptivn´ı systém, ale jeho j´ adro bylo nepreemptivn´ı. • pˇri preemptivn´ım pl´ anov´ an´ı m˚ uˇze b´ yt proces kdykoliv pˇreruˇsen a ˇr´ızen´ı pˇred´ ano jinému procesu. Proces si proto nikdy nem˚ uˇze b´ yt jist´ y, ˇze urˇcitou operaci (v´ıce neˇz jednu intstrukci, kromˇe systémov´ ych volán´ı se zaruˇcenou atomiˇcnost´ı) provede atomicky, bez ovlivnˇen´ı ostatn´ımi procesy. Pokud je tˇreba zajistit atomiˇcnost nˇejaké akce, mus´ı se procesy navzájem synchronizovat. Pˇri kooperativn´ım pl´ anován´ı problém synchronizace odpadá (atomická posloupnost operac´ı se zajist´ı t´ım, ˇze se proces bˇehem n´ı nevzdá procesoru). 124

Prioritn´ı tˇ r´ıdy • syst´ emov´ a – priorita 60 aˇz 99 – rezervov´ ana pro systémové procesy (pageout, sched, . . . ) – pevn´ a priorita • real-time – priorita 100 aˇz 159 – pevn´ a priorita – pro kaˇzdou hodnotu priority definováno ˇcasové kvantum • sd´ılen´ı ˇ casu (time-shared) – priorita 0 aˇz 59 – promˇenn´ a dvousloˇzková priorita, pevná uˇzivatelská a promˇenn´ a systémová ˇcást – pokud proces hodnˇe vyuˇz´ıvá procesor, je mu sniˇzována priorita (a zvˇetˇsováno ˇcasové kvantum)

• systémov´ a tˇr´ıda je pouˇz´ıv´ ana pouze jádrem, uˇzivatelsk´ y proces bˇeˇz´ıc´ı v reˇzimu j´ adra si ponech´ av´ a svou plánovac´ı charakteristiku. • procesy ve tˇr´ıdˇe re´ alného ˇcasu maj´ı nejvyˇsˇs´ı prioritu, proto mus´ı b´ yt správnˇe nakonfigurov´ any, aby nezablokovaly zbytek systému. • jestliˇze je proces ve tˇr´ıdˇe sd´ılen´ı ˇcasu uspán a ˇceká na nˇejakou událost, je mu doˇcasnˇe pˇriˇrazena systémov´ a priorita. Po probuzen´ı se takov´ y proces dostane na procesor dˇr´ıve, neˇz ostatn´ı procesy, které nesp´ı. • pevn´ a ˇc´ ast priority procesu ve tˇr´ıdˇe sd´ılen´ı ˇcasu se dá nastavit pomoc´ı int setpriority(int which, id t who, int prio ); nebo int nice(int incr ); Hodnota which ud´ av´ a co bude v argumentu who. Pokud je napˇr. which PRIO PGRP, bude v who ˇc´ıslo skupiny proces˚ u. Pozor na volán´ı nice které vrac´ı novou hodnotu nice. Protoˇze je -1 validn´ı hodnota, je potˇreba pˇred vol´ an´ı vyˇcistit errno a pokud funkce vrát´ı -1 tak ji zkontrolovat. • prioritn´ı tˇr´ıdu a hodnotu nice daného procesu lze zobrazit pˇrep´ınaˇcem -l programu ps(1) nebo pomoc´ı specifikace hodnot které se maj´ı vypsat. • Pˇr´ıklad: hodnoty priority maj´ı na r˚ uzn´ ych systémech r˚ uzné ˇskály. Napˇr. na Mac OS X 10.9 m´ a spuˇstˇen´ y proces hodnotu priority 30, po zv´ yˇsen´ı hodnoty nice (proces je ”hodnˇejˇs´ı”na ostatn´ı procesy a dobrovolnˇe tedy sn´ıˇzil svoji prioritu) se mu hodnota prorita sn´ıˇz´ı na 21 coˇz na Mac OS X znamená i sn´ıˇzen´ı priority: 125

$ sleep 200 & [1] 36877 $ ps -O pri,nice -p $! PID PRI NI TT STAT 36877 31 0 s003 S $ renice 10 -p $! $ ps -O pri,nice -p $! PID PRI NI TT STAT 36877 21 10 s003 SN

TIME COMMAND 0:00.00 sleep 200

TIME COMMAND 0:00.00 sleep 200

Na Linuxu 3.10 to ale bude vypadat jinak - po zv´ yˇsen´ı hodnoty nice se zv´ yˇs´ı i hodnota priority, to ale v této verzi znamená, ˇze proces bude bˇeˇzet s prioritou niˇzˇs´ı.

Skupiny proces˚ u, ˇ r´ızen´ı termin´ al˚ u • kaˇzd´ y proces patˇr´ı do skupiny proces˚ u, tzv. process group • kaˇzd´ a skupina m˚ uˇze m´ıt vedouc´ı proces, tzv. group leader • kaˇzd´ y proces m˚ uˇze m´ıt ˇr´ıd´ıc´ı terminál (je to obvykle login termin´ al), tzv. controlling terminal • speci´ aln´ı soubor /dev/tty je asociován s ˇr´ıd´ıc´ım terminálem kaˇzdého procesu • kaˇzd´ y termin´ al je asociován se skupinou proces˚ u, tato skupina se naz´ yv´ a ˇr´ıd´ıc´ı skupina (controlling group) • kontrola job˚ u (job control ) je mechanizmus, jak pozastavovat a probouzet skupiny proces˚ u a ˇr´ıdit jejich pˇr´ıstup k terminál˚ um • session (relace) je kolekce skupin proces˚ u vytvoˇrená pro u ´ˇcely ˇr´ızen´ı job˚ u

• kdyˇz se uˇzivatel pˇrihl´ as´ı do systému, je vytvoˇrená nová relace, která se skládá z jedné skupiny proces˚ u, ve které je jeden proces – ten kter´ y vykonává uˇzivatel˚ uv shell. Tento proces je zároveˇ n vedouc´ı této jediné skupiny proces˚ u a také je vedouc´ı relace. V pˇr´ıpadˇe, ˇze job control je povolen, kaˇzd´ y pˇr´ıkaz nebo kolona pˇr´ıkaz˚ u vytvoˇr´ı novou skupinu proces˚ u, jeden z proces˚ u v kaˇzdé skupinˇe se vˇzdy stane vedouc´ım procesem dané skupiny. Jedna ze skupin m˚ uˇze bˇeˇzet na popˇred´ı, ostatn´ı bˇeˇz´ı na pozad´ı. Signály, které jsou generované z kl´ avesnice (tj. stiskem kombinace kláves, nemysl´ı se t´ım spuˇstˇen´ı pˇr´ıkazu kill!), jsou zasl´ any pouze skupinˇe, která bˇeˇz´ı na popˇred´ı. • pokud job control nen´ı zapnut, znamená spustˇen´ı pˇr´ıkazu na pozad´ı pouze to, ˇze shell neˇcek´ a na jeho ukonˇcen´ı. Existuje pouze jedna skupina proces˚ u,

126

sign´ aly z kl´ avesnice se pos´ılaj´ı vˇsem proces˚ um beˇz´ıc´ım na popˇred´ı i na pozad´ı. Nelze pˇresouvat procesy z pozad´ı na popˇred´ı a naopak. • kdyˇz proces, kter´ y m´ a kontroln´ı terminál, otevˇre soubor /dev/tty, tak se asociuje se sv´ ym kontroln´ım terminálem. Tj. pokud dva r˚ uzné procesy z r˚ uzn´ ych relac´ı otevˇrou tento soubor, pˇristupuj´ı oba k r˚ uzn´ ym terminál˚ um. • v bashi se skupina proces˚ u (job) pozastav´ı pomoc´ı Ctrl-Z, a rozbˇehne pˇres ,,fg %N” kde N je ˇc´ıslo jobu podle v´ ypisu pˇr´ıkazu jobs. V´ıce informac´ı viz sekce ,,JOB CONTROL” v manuálové stránce pro bash.

Identifikace procesu pid t getpid(void); • vrac´ı proces ID volaj´ıc´ıho procesu. pid t getpgrp(void); • vrac´ı ID skupiny proces˚ u, do které patˇr´ı volaj´ıc´ı proces. pid t getppid(void); • vrac´ı proces ID rodiˇce. pid t getsid(pid t pid ); • vrac´ı group ID vedouc´ıho procesu session (sezen´ı, terminálové relace) pro proces pid (0 znamená pro volaj´ıc´ı proces)

skupiny proces˚ u umoˇzn ˇuj´ı pos´ılat signály najednou celé skupinˇe. session (relace, sezen´ı) je kolekce proces˚ u vytvoˇrená pro u ´ˇcely ˇr´ızen´ı prac´ı (job control ). Procesy sezen´ı sd´ılej´ı jeden ˇr´ıd´ıc´ı termin´ al. Session zahrnuje jednu nebo v´ıce skupin proces˚ u. Max. jedna skupina v rámci sezen´ı bˇeˇz´ı na popˇred´ı (foreground process group) a má pˇr´ıstup k ˇr´ıdic´ımu terminálu pro vstup i v´ ystup, ostatn´ı bˇeˇz´ı na pozad´ı (background process groups) a maj´ı k ˇr´ıdic´ımu termin´ alu pˇr´ıstup volitelnˇe jen pro v´ ystup nebo v˚ ubec (nepovolená operace s termin´ alem pozastav´ı proces). rodiˇ covsk´ y proces: Kaˇzd´ y proces (kromˇe swapperu, pid == 0) má rodiˇce, tj. proces, kter´ y ho stvoˇril vol´ an´ım fork. Jestliˇze rodiˇc skonˇc´ı dˇr´ıve neˇz d´ıtˇe, adoptivn´ım rodiˇcem se st´ av´ a proces init s pid == 1, kter´ y se také postará o uklizen´ı zombie po skonˇcen´ı procesu. • Pozor na to, ˇze zjiˇst’ovat ˇze rodiˇc skonˇcil pomoc´ı kontroly hodnoty vrácené z getppid na hodnotu 1 (coˇz je bˇeˇznˇe proces init resp. jeho ekvivalent), 127

nen´ı portabiln´ı. V r˚ uzn´ ych virtualizovan´ ych prostˇred´ıch (PID namespaces v Linux, Zones v Solarisu) to nemus´ı platit. Viz pˇr´ıklad session/getppid.c .

Nastaven´ı skupiny/sezen´ı int setpgid(pid t pid, pid t pgid ); • nastav´ı process group ID procesu s pid na pgid. pid t setsid(void); • vytvoˇr´ı novou session, volaj´ıc´ı proces se stane vedouc´ım sezen´ı i skupiny proces˚ u.

• pro vol´ an´ı setpgid plat´ı: 1. pid == pgid : proces s pid se stane vedouc´ım skupiny proces˚ u 2. pid != pgid : proces s pid se stane ˇclenem skupiny proces˚ u • Proces, kter´ y jeˇstˇe nen´ı vedouc´ım skupiny proces˚ u, se m˚ uˇze stát vedouc´ım sezen´ı a z´ aroveˇ n skupiny proces˚ u volán´ım setsid. Jestliˇze proces uˇz je vedouc´ım skupiny, setsid selˇze, pak je tˇreba provést fork a setsid zavolat v synovském procesu. Takov´ y proces nemá ˇr´ıdic´ı terminál, m˚ uˇze ho z´ıskat otevˇren´ım termin´ alu, kter´ y jeˇstˇe nen´ı ˇr´ıdic´ım terminálem sezen´ı, kdyˇz pˇri open neuvede pˇr´ıznak O NOCTTY, nebo jin´ ym implementaˇcnˇe závisl´ ym zp˚ usobem.

128

Vytvoˇ ren´ı procesu: fork() getpid() == 1234 switch(pid = case -1: case 0: default: } rodiˇc (pokraˇcuje)

fork()) { /* Chyba */ /* D´ ıtˇ e */ /* Rodiˇ c */

d´ıtˇe (nový proces)

getpid()==1234, pid==2345 switch(pid = fork()) { case -1: /* Chyba */ case 0: /* D´ ıtˇ e */ default: /* Rodiˇ c */ }

getpid()==2345, pid==0 switch(pid = case -1: case 0: default: }

fork()) { /* Chyba */ /* D´ ıtˇ e */ /* Rodiˇ c */

• d´ıtˇe je témˇeˇr pˇresnou kopi´ı rodiˇce. Základn´ı atributy, které se liˇs´ı, jsou: – PID procesu a parent PID – pokud mˇel rodiˇc v´ıce vláken, má syn pouze to, které fork zavolalo; o tom v´ıce na stranˇe 229, aˇz se dostaneme k vlákn˚ um. Tyto informace by kaˇzdop´ adnˇe mˇely b´ yt v manuálové stránce fork(2). – u ´ˇctovac´ı ˇcasy se nastav´ı na 0 – nedˇed´ı se nastaven´ı alarm a zámky soubor˚ u • co je d˚ uleˇzité je, ˇze tabulky deskriptor˚ u jsou stejné v obou procesech, ˇc´ımˇz v´ıce proces˚ u m˚ uˇze sd´ılet a posunovat spoleˇcnou pozici v souboru, a také ˇze masky sign´ al˚ u se nemˇen´ı, viz strana 164. • pro urychlen´ı a menˇs´ı spotˇrebu pamˇeti se adresov´ y prostor nekop´ıruje, ale pouˇz´ıv´ a se mechanizmus copy-on-write. • je logické, ˇze pˇri u ´spˇeˇsném proveden´ı volán´ı otec dostane jako návratovou hodnotu vol´ an´ı fork PID syna a syn ˇc´ıslo 0; syn si totiˇz m˚ uˇze velmi jednoduˇse sv˚ uj vlastn´ı PID zjistit volán´ım getpid. Otec ale neum´ı jednoduˇse zjistit PID syna, nav´ıc v situaci, pokud jiˇz dˇr´ıve vytvoˇril syny jiné. • pˇr´ıklad: fork/fork.c • zaj´ımavost´ı m˚ uˇze b´ yt vol´ an´ı vfork, kter´ ym se kdysi obcházel problém, kdy draze vytvoˇren´ y proces byl okamˇzitˇe pˇrepsán následn´ ym volán´ım exec. Tento problém byl d´ avno vyˇreˇsen jiˇz zm´ınˇen´ ym pouˇzit´ım mechanizmu copy-onwrite, ale pˇr´ıklad fork/vfork.c ukazuje, jak toto volán´ı fungovalo. 129

Spuˇ stˇ en´ı programu: exec extern char **environ; int execl(const char *path, const char *arg0, ... ); • spust´ı program definovan´ y celou cestou path, dalˇs´ı argumenty se pak pˇredaj´ı programu v parametrech argc a argv funkce main. Seznam argument˚ u je ukonˇcen pomoc´ı (char *)0, tj. NULL. arg0 by mˇel obsahovat jméno programu (tj. ne celou cestu) • u ´spˇeˇsné vol´ an´ı execl se nikdy nevrát´ı, protoˇze spuˇstˇen´ y program zcela nahrad´ı dosavadn´ı adresov´ y prostor procesu. • program dˇed´ı promˇenné prostˇred´ı, tj. obsah environ. • handlery sign´ al˚ u se nahrad´ı implicitn´ı obsluhou • zavˇrou se deskriptory soubor˚ u, které maj´ı nastaven´ y pˇr´ıznak FD CLOEXEC (implicitnˇe nen´ı nastaven).

• o sign´ alech v´ıce na stranˇe 153 • v path mus´ı b´ yt cel´ a (absolutn´ı nebo relativn´ı) cesta ke spustitelnému souboru. Obsah promˇenné prostˇred´ı PATH se pouˇz´ıvá jen pˇri volán´ıch execlp a execvp, kdyˇz argument path neobsahuje znak ’/’. • nˇekdy se pouˇz´ıv´ a argv[0] r˚ uzné od jména spustitelného souboru. Napˇr. login vloˇz´ı na zaˇc´ atek jména spouˇstˇeného shellu znak ’-’. Shell podle toho pozn´ a, ˇze m´ a fungovat jako login-shell, tj. napˇr´ıklad naˇc´ıst /etc/profile. • exec nepˇred´ a kontrolu naˇctenému programu v pamˇeti pˇr´ımo, ale pˇres dynamick´ y linker (téˇz naz´ yvan´ y loader ), poté co ho (= toho loader a) namapuje do adresového prostoru procesu. Loader následnˇe namapuje potˇrebné dynamické objekty a teprve poté pˇredá kontrolu aplikaci. Viz také strana 36. Pro jednoduché ovˇeˇren´ı staˇc´ı vytvoˇrit program obsahuj´ıc´ı pouze tˇreba volán´ı open. Tento program pak spust’te pomoc´ı truss(1) takto: truss ./a.out. Uvid´ıte, kter´ a vol´ an´ı se pouˇzij´ı jeˇstˇe pˇredt´ım, neˇz se zavolá open. • exec nezmˇen´ı hodnoty RUID a RGID. A pokud je to program s nastaven´ ym SUID bitem, tak se EUID a uschované UID nastav´ı na UID majitele spustitelného souboru. • dneˇsn´ı unixové systémy um´ı spouˇstˇet i skripty, které zaˇc´ınaj´ı ˇrádkem #!/interpreter path /interpreter name [args]

130

Varianty sluˇ zby exec int execv(const char *path, char *const argv []); • obdoba execl(), ale argumenty jsou v poli argv, jehoˇz posledn´ı prvek je NULL. int execle(const char *path, const char *arg0, ... , char *const envp []); • obdoba execl(), ale m´ısto environ se pouˇzije envp. int execve(const char *path, char *const argv [], char *const envp []); • obdoba execv(), ale m´ısto environ se pouˇzije envp. int execlp(const char *file, const char *arg0, ...); int execvp(const char *file, char *const argv []); • obdoby execl() a execv(), ale pro hledán´ı spustitelného souboru se pouˇzije promˇenná PATH.

• l = list (tj. line´ arn´ı seznam argument˚ u), v = vector (tj. pole ukazatel˚ u na ˇretˇezce), e = environment (tj. pˇredávaj´ı se promˇenné prostˇred´ı), p = PATH. • kromˇe execlp a execvp je nutné jméno programu vˇzdy zadávat celou cestu. • vˇsechny varianty kromˇe execle a execve pˇredávaj´ı spouˇstˇenému programu také své aktu´ aln´ı prostˇred´ı, tj. obsah pole environ. • z mˇe nezn´ am´ ych historick´ ych d˚ uvod˚ u neexistuje volán´ı s p a e dohromady. • pˇr´ıklad: exec/exec-date.c • n´ asleduj´ıc´ı pouˇzit´ı vol´ an´ı execl je ˇspatnˇe, protoˇze mu chyb´ı povinn´ y parametr pro argv[0]: execl("/bin/ls", NULL); Na nˇekter´ ych systémech to má zaj´ımav´ y efekt. Jelikoˇz je NULL brán jako oˇcek´ avan´ y argv[0], dalˇs´ı data na zásobn´ıku jsou akceptována jako ukazatele na ˇretˇezce, dokud se nenalezne dalˇs´ı NULL. V naˇsem pˇr´ıpadˇe tak pˇr´ıkaz ls zkouˇs´ı zobrazit informace o souborech, jako jejichˇz jména jsou pouˇzity ˇretˇezce nastaven´ı promˇenn´ ych prostˇred´ı z pole environ, o nichˇz jiˇz v´ıme, ˇze se vol´ an´ım execl spouˇstˇenému programu pˇredávaj´ı: $ ./a.out : BLOCKSIZE=K: No such file or directory : FTP_PASSIVE_MODE=YES: No such file or directory 131

: HISTCONTROL=ignoredups: No such file or directory : HISTSIZE=10000: No such file or directory ... ...

Form´ at spustiteln´ eho souboru • Common Object File Format (COFF) – starˇs´ı System V • Extensible Linking Format (ELF) – nov´ y v SVR4 • ˇcasto se mluv´ı o a.out formátu, protoˇze tak se jmenuje (pokud nen´ı pouˇzit pˇrep´ınaˇc -o) v´ ystup linkeru. • Form´ at ELF:

hlaviˇcka souboru tabulka programov´ ych hlaviˇcek sekce 1 .. . sekce N tabulka hlaviˇcek sekc´ı

• Standard nestanovuje form´ at spustitelného souboru. I kdyˇz vˇetˇsina unixov´ ych systém˚ u pˇreˇsla na ELF, st´ ale se najdou mainstreamové systémy pouˇz´ıvaj´ıc´ı jiné form´ aty. Napˇr. Mac OS X (coˇz je certifikovan´ y UNIX) pouˇz´ıvá tzv. MachO form´ at. Stejnˇe jako ELF je strukturovan´ y, odliˇsuje se napˇr. v tom, ˇze za hlaviˇckou n´ asleduj´ı tzv. load commands, které se odkazuj´ı na sekce v dalˇs´ı ˇc´ asti. Za nimi n´ asleduj´ı samotné segmenty, které se skládaj´ı ze sekc´ı. Kaˇzd´ y segment je u ´sek virtu´ aln´ı pamˇeti, kterou dynamick´ y linker mapuje do adresového prostoru procesu. Kaˇzdá sekce obsahuje kód nebo data daného typu. • Hlaviˇcka souboru (ELF header ) obsahuje základn´ı informace o souboru. • Na Solarisu je k dispozici program elfdump umoˇzn ˇuj´ıc´ı zobrazen´ı prakticky vˇsech sekc´ı v ELF souboru a jejich obsahu v lidsky ˇcitelné formˇe. V Linuxu lze pouˇz´ıt program readelf, jeho funkcionalita je ovˇsem proti elfdump omezena. • Tabulka programov´ ych hlaviˇcek (program header table) je pˇr´ıtomna pouze u soubor˚ u obsahuj´ıc´ıch spustitelné programy, zobraz´ı se pomoc´ı “elfdump -p”. Obsahuje informaci o rozvrˇzen´ı virtuáln´ı pamˇeti procesu. • Sekce obsahuj´ı instrukce, data, tabulku symbol˚ u, relokaˇcn´ı data, apod. • Tabulka hlaviˇcek sekc´ı (section header table) obsahuje sluˇzebn´ı informace pro linker, “elfdump -c”. 132

• Nen´ı to tak d´ avno co nˇekteré unixové systémy pˇreˇsly na ELF. Napˇr. OpenBSD pˇreˇslo z a.out form´ atu (coˇz je dalˇs´ı formát spustiteln´ ych soubor˚ u, viz a.out(5) man page na OpenBSD) na ELF ve verzi 3.4 v roce 2003. Proti ELFu je a.out mnohem jednoduˇsˇs´ı a ménˇe obecn´ y, hod´ı se tedy dobˇre na zkoumán´ı fundament´ aln´ıch princip˚ u zav´ adˇen´ı spustiteln´ ych soubor˚ u do pamˇeti. Základem hlaviˇcka (obsahuj´ıc´ı napˇr. informace o tom zda spustiteln´ y soubor vyˇzaduje sluˇzby run time linkeru nebo zda obsahuje Position Independent Code) a pak dalˇs´ıch nepovinn´ ych 6 sekc´ı (text, data, relokace v textovém segmentu, relokace v datovém segmentu, tabulka symbol˚ u, tabulka string˚ u koresponduj´ıc´ıch s jednotliv´ ymi symboly). • Dnes je naprosto bˇeˇzné ˇze virtuáln´ı adresy spustitelného souboru, namapovan´ ych knihoven, z´ asobn´ıku a heapu jsou náhodné, mˇen´ı se pˇri kaˇzdém spuˇstˇen´ı procesu. Tato technika (Adress Space Layout Randomization) slouˇz´ı k znesnadnˇen´ı u ´tok˚ u, které potˇrebuj´ı znát napˇr. adresy symbol˚ u v knihovnˇe libc nebo z´ asobn´ıku. Poprvé s touto ideou pˇriˇsel Linux, OpenBSD byl prvn´ı systém kter´ y ji zaˇcal pouˇz´ıvat pro vˇsechny programy implicitnˇe. R˚ uzné systémy aplikuj´ı tuto techniku s r˚ uzn´ ymi parametry a na r˚ uzné ˇcásti programu. Obecnˇeji vzato lze vn´ aˇset n´ ahodnost do dalˇs´ıch ˇcást´ı systému (napˇr. ID proces˚ u, inici´ aln´ı sekvenˇcn´ı ˇc´ısla pro TCP apod.).

Ukonˇ cen´ı procesu void exit(int status ); • ukonˇc´ı proces s n´ avratov´ ym kódem status. • nikdy se nevr´ at´ı na instrukci následuj´ıc´ı za volán´ım. pid t wait(int *stat loc ); • poˇck´ a, aˇz skonˇc´ı nˇekter´ y synovsk´ y proces, vrát´ı jeho PID a do stat_loc uloˇz´ı n´ avratov´ y kód, kter´ y lze dále testovat: – WIFEXITED(stat val) . . . proces volal exit() – WEXITSTATUS(stat val) . . . argument exit() – WIFSIGNALED(stat val) . . . proces dostal signál – WTERMSIG(stat val) . . . ˇc´ıslo signálu – WIFSTOPPED(stat val) . . . proces pozastaven – WSTOPSIG(stat val) . . . ˇc´ıslo signálu pid t waitpid(pid t pid, int *stat loc, int opts ); • ˇcek´ an´ı na jeden proces.

• status loc roven NULL znaˇc´ı ignoraci statusu • funkce exit funguje jako exit s t´ım, ˇze se neprovád´ı flush stdio stream˚ ua nevolaj´ı se funkce nastavené pomoc´ı atexit

133

• ve standardu je jeˇstˇe WIFCONTINUED(stat val), coˇz znaˇc´ı opˇetné rozbˇehnut´ı procesu po jeho pˇredchoz´ım zastaven´ı, je to ale souˇcást jistého rozˇs´ıˇren´ı, které nemus´ı vˇsechny systémy podporovat. • pozn´ amka – pozastavit proces lze pomoc´ı ,,kill -STOP ”, rozbˇehnout pak pˇres ,,kill -CONT ”. • opts ve waitpid jsou OR-kombinace následuj´ıch pˇr´ıznak˚ u: – WNOHANG . . . neˇcek´ a, pokud nen´ı status okamˇzitˇe k dispozici – WUNTRACED . . . vr´ at´ı status i zastaven´ ych proces˚ u, které jeˇstˇe nebyly testov´ any po jejich zastaven´ı. WSTOPPED m˚ uˇze na nˇekter´ ych systémech b´ yt synonymem pro WUNTRACED, nen´ı ale souˇcást´ı normy. – WCONTINUED . . . vr´ at´ı status i tˇech proces˚ u, které jeˇstˇe nebyly testovány od pokraˇcov´ an´ı procesu po zastaven´ı. Bez tohoto pˇr´ıznaku nejsou takové procesy reportov´ any. Souˇcást´ı stejného rozˇs´ıˇren´ı jako WIFCONTINUED. – pro WUNTRACED a WCONTINUED plat´ı, ˇze v pˇrenositeln´ ych aplikac´ıch byste tyto pˇr´ıznaky mˇeli pouˇz´ıvat jen kdyˇz je v definováno makro POSIX JOB CONTROL. • pid ve waitpid: – == -1 . . . libovolné d´ıtˇe – > 0 . . . jedno d´ıtˇe – == 0 . . . d´ıtˇe ve stejné skupinˇe proces˚ u jako volaj´ıc´ı proces – < -1 . . . d´ıtˇe ve skupinˇe abs(pid) • rodiˇc by mˇel vˇzdy na své dˇeti zavolat wait nebo waitpid, protoˇze jinak se v systému hromad´ı zombie (ukonˇcené procesy, které pouze ˇcekaj´ı, aˇz si rodiˇc pˇreˇcte jejich n´ avratovou hodnotu). Hromadˇen´ı tˇechto zombie proces˚ uv tabulce proces˚ u kernelu m˚ uˇze skonˇcit vyˇcerpán´ım veˇskeré volné pamˇeti, takˇze pozor na to. Pokud takov´ y rodiˇc sám skonˇc´ı, vˇsechny jeho syny adoptuje process init, kter´ y se tak postará i o vˇsechny zombie procesy. • pˇr´ıklad: wait/wait.c

134

Pˇ r´ıklad: spuˇ stˇ en´ı programu a ˇ cek´ an´ı int status; pid = fork() rodiˇc if(pid > 0)

wait(&status);

d´ıtˇe else execl("/bin/ls", "ls", "/", NULL); /bin/ls int main(int argc, char *argv[]) { ... exit(result); }

• toto je klasick´ y zp˚ usob jak spustit nˇejak´ y program a po jeho skonˇcen´ı pokraˇcovat. Rodiˇc nemus´ı jen ˇcekat na ukonˇcen´ı potomka, ale m˚ uˇze vykonávat d´ al sv˚ uj k´ od. • pozor na to, ˇze aˇckoli to na obrázku tak vypadá, návratová hodnota je pouze souˇc´ ast toho, co dostanete z volán´ı wait. Na jej´ı z´ıskán´ı je potˇreba pouˇz´ıt makra z pˇredchoz´ıho slajdu.

135

Roura: pipe() int pipe(int fildes [2]); • vytvoˇr´ı rouru a dva deskriptory – fildes[0] . . . ˇcten´ı z roury – fildes[1] . . . z´ apis do roury • roura zajiˇst’uje synchronizaci ˇcten´ı a zápisu: – zapisuj´ıc´ı proces se zablokuje, kdyˇz je roura plná, – ˇctouc´ı proces se zablokuje, kdyˇz je roura prázdná. • ˇctouc´ı proces pˇreˇcte konec souboru (tj. read() vrát´ı 0), pokud jsou uzavˇreny vˇsechny kopie fildes[1]. • pojmenovan´ a roura (vytvoˇrená volán´ım mkfifo()) funguje stejnˇe, ale m´ a pˇridˇelené jméno v systému soubor˚ u a mohou ji tedy pouˇz´ıvat libovolné procesy.

• nepojmenovanou rouru vytváˇr´ı jeden proces a m˚ uˇze ji pˇredat pouze sv´ ym potomk˚ um (pomoc´ı deskriptor˚ u zdˇedˇen´ ych pˇri fork). Toto omezen´ı se dá obej´ıt pomoc´ı pˇred´ an´ı otevˇreného deskriptoru pˇres unix-domain socket. • jestliˇze funkce write zap´ıˇse do roury nejv´ yˇse PIPE BUF (systémová konstanta) bajt˚ u, je zaruˇceno, ˇze z´ apis bude atomick´ y, tj. tato data nebudou proloˇzena daty zapisovan´ ymi souˇcasnˇe jin´ ymi procesy. • v normˇe SUSv3 nen´ı specifikováno, zda fildes[0] je také otevˇren´ y pro zápis a zda fildes[1] je téˇz otevˇren´ y pro ˇcten´ı. Pozor na to, ˇze napˇr´ıklad FreeBSD a Solaris maj´ı roury obousmˇerné, ale Linux (kdyˇz jsem se naposledy d´ıval) ne. Je proto velmi vhodné poˇc´ıtat pouze s jednosmˇern´ ymi rourami. • d˚ uleˇ zit´ e: pro ˇcten´ı/z´ apis z/do roury plat´ı stejné podm´ınky jako pro pojmenovanou rouru, jak jsou uvedeny na stranˇe 104. To také znamená, ˇze jedin´ y zp˚ usob, jak ˇcten´ aˇrovi roury “poslat” end-of-file je, ˇze vˇsichni zapisovatelé mus´ı zavˇr´ıt pˇr´ısluˇsn´ y deskriptor pro zápis, pˇr´ıpadnˇe vˇsechny takové deskriptory, maj´ı-li jich v´ıce. • pˇr´ıklady: pipe/broken-pipe.c , pipe/main.c

136

Pˇ r´ıklad: roura mezi dvˇ ema procesy shell: ls / | more

int pd[2]; pipe(pd); switch(fork()) {

producent (d´ıtˇe)

konzument (rodiˇc) default:

case 0: close(1);

close(0);

dup(pd[1]);

dup(pd[0]);

close(pd[0]);

close(pd[0]);

close(pd[1]);

close(pd[1]);

execl("/bin/ls", "ls",

execl("/bin/more", "more", NULL);

"/", NULL);

pd[1]

pd[0]

/bin/ls

/bin/more

• zavˇren´ı z´ apisového deskriptoru pd[1] (ozn. .) v procesu konzumenta je nutné, protoˇze jinak se na rouˇre nikdy nedetekuje konec souboru. • ˇctec´ı deskriptor v procesu producenta pd[0] je také vhodné zav´ırat (ozn. .), protoˇze kdyˇz konzument pˇredˇcasnˇe skonˇc´ı, dostane producent signál SIGPIPE. Kbyby deskriptor v producentovi nebyl zavˇren, producent se nedozv´ı, ˇze konzument skonˇcil, a po naplnˇen´ı bufferu roury v jádru se zablokuje. • pokud nem´ ame jistotu, ˇze pˇred volán´ım pipe byl otevˇren deskriptor 0, mus´ıme v producentovi pouˇz´ıt dup2(pd[1], 1), protoˇze dup(pd[1]) by mohl vrátit deskriptor 0 m´ısto poˇzadovaného 1. Také je tˇreba testovat, zda nenastala situace pd[1] == 1, abychom si nechtˇenˇe nezavˇreli rouru. Podobnˇe je tˇreba otestovat pd[0] == 0 v konzumentovi. • je lepˇs´ı vytv´ aˇret rouru od syna k otci, protoˇze typicky nejdˇr´ıv skonˇc´ı proces zapisuj´ıc´ı do roury, ˇctouc´ı proces pˇreˇcte zbylá data, zpracuje je, nˇeco vyp´ıˇse a teprve pak skonˇc´ı. D˚ uvodem je to, ˇze shell, kter´ y pˇr´ısluˇsnou kolonu pˇr´ıkaz˚ u spouˇst´ı, ˇceká na ukonˇcen´ı otce a o jeho syny se nezaj´ımá. Kdyby tedy smˇeˇrovala roura od otce k synovi, otec jako producent dat skonˇc´ı, shell vyp´ıˇse prompt, ale pak jeˇstˇe syn, kter´ y pln´ı funkci konzumenta, m˚ uˇze vypsat nˇejak´ y v´ ystup. Moˇzn´ ym ˇreˇsen´ım je ˇcek´ an´ı otce na skonˇcen´ı syna, jenˇze to se nedá zajistit, pokud otec provede exec. • p˚ uvodn´ı Bourne shell stav´ı rouru tak, ˇze posledn´ı proces v rouˇre vytvoˇr´ı pˇredposledn´ı jako svého syna, ten vytvoˇr´ı pˇredchoz´ı proces a tak se postupuje aˇz k zaˇc´ atku roury. 137

• v shellu bash jsou vˇsechny procesy v rouˇre pˇr´ımo potomky shellu (shell volá fork tolikr´ at, jak dlouh´ a je roura). Shell pˇred vypsán´ım promptu ˇceká, aˇz vˇsechny procesy roury skonˇc´ı.

Sd´ılen´ a pamˇ et’ – u ´ vod • pajpy a soubory jako metody meziprocesové komunikace vyˇzaduj´ı systémov´ a volán´ı • v´ yhoda: procesy nemohou poˇskodit adresov´ y prostor jiného procesu • nev´ yhoda: velk´ a reˇzie pro systémová volán´ı, typicky read, write • sd´ılen´ a pamˇet’ je namapován´ı ˇcásti pamˇeti do adresového prostoru v´ıce proces˚ u • odstranˇen´ı nev´ yhody, ztráta dosavadn´ı v´ yhody • synchronizace pˇr´ıstupu do sd´ılené pamˇeti – System V semafory – POSIX semafory bez nutnosti systémového volán´ı v bˇeˇzném pˇr´ıpadˇe

• mapov´ an´ı soubor˚ u do pamˇeti je jednou z implementac´ı sd´ılené pamˇeti. Pro popis u ´seku sd´ılené pamˇeti pouˇz´ıvá soubor. • takto implementovan´ a sd´ılená pamˇet’ je tedy pravidelnˇe zapisována na disk • pro sd´ılen´ı bez reˇzie z´ apisu zmˇenˇen´ ych dat na disk je moˇzné pouˇz´ıt memory based filesystém, napˇr´ıklad tmpfs (Solaris, NetBSD – zde byl tmpfs napsán v roce 2005 jako souˇc´ ast Summer of Code sponzorovaného firmou Google, FreeBSD m´ a podobnou vlastnost pod názvem memory disk ). Jako tzv. backing store pro pamˇet’ové str´ anky patˇr´ıc´ı tˇemto filesystém˚ um je obecnˇe moˇzné pouˇz´ıt swap oblast na disku. • pro synchronizaci pˇr´ıstupu do sd´ılené pamˇeti se vˇetˇsinou pouˇz´ıvaj´ı semafory.

138

Mapov´ an´ı soubor˚ u do pamˇ eti (1) void *mmap(void *addr, size t len, int prot, int flags, int fildes, off t off ); • do pamˇet’ového prostoru procesu od adresy addr (0 . . . adresu pˇridˇel´ı j´ adro) namapuje u ´sek délky len zaˇc´ınaj´ıc´ı na pozici off souboru reprezentovaného deskriptorem fildes. • vrac´ı adresu namapovaného u ´seku nebo MAP FAILED. • v prot je OR-kombinace PROT READ (lze ˇc´ıst), PROT WRITE (lze zapisovat), PROT EXEC (lze spouˇstˇet), nebo PROT NONE (nelze k dat˚ um pˇristupovat). • ve flags je OR-kombinace MAP PRIVATE (zmˇeny jsou privátn´ı pro proces, neukl´ adaj´ı se do souboru), MAP SHARED (zmˇeny se ukl´ adaj´ı do souboru), MAP FIXED (jádro nezmˇen´ı addr).

• Pˇr´ıklady: mmap/reverse.c , mmap/map-nocore.c • v pˇr´ıznac´ıch mus´ı b´ yt pˇr´ıtomen pr´ avˇ e jeden z MAP PRIVATE a MAP SHARED • mapov´ an´ı soubor˚ u do pamˇeti je alternativou ke zpracován´ı soubor˚ u pomoc´ı read, write, lseek. Po namapován´ı lze se souborem pracovat jako s datovou strukturou v pamˇeti. Soubor se nekop´ıruje cel´ y do pamˇeti, alokuj´ı se pouze str´ anky na které se pˇristupuje. Pokud je potˇreba stránku uvolnit, obsah se ukl´ ad´ a zpˇet do souboru (kdyˇz je pouˇzit MAP SHARED – tento zp˚ usob namapov´ an´ı je tedy ekvivalentn´ı tomu, kdy program zap´ıˇse do stejného souboru pomoc´ı write(2)) nebo do swapu – pouˇz´ıvá se mechanizmus copy-on-write (pˇri MAP PRIVATE). • pro namapov´ an´ı souboru do pamˇeti tedy potˇrebuji soubor nejdˇr´ıve otevˇr´ıt pomoc´ı open. M´ od v prot nem˚ uˇze b´ yt “vyˇsˇs´ı” neˇz bylo specifikováno v módu uˇze b´ yt problém pro open. Pouˇzit´ı MAP FIXED se nedoporuˇcuje, protoˇze to m˚ pro pˇrenositelnost k´ odu. • varov´ an´ı: toto se t´ yk´ a pouze MAP SHARED – pokud je soubor jin´ ym procesem zkr´ acen tak, ˇze zkr´ acen´ı se t´ yká i právˇe namapované ˇcásti, pˇri pˇr´ıstupu do ˇ sen´ım je takové pamˇeti je procesu zaslán signál SIGBUS resp. SIGSEGV. Reˇ pouˇz´ıt mandatory locking, to ale nen´ı vˇsude implementováno. V pˇr´ıpadˇe, ˇze je namapovan´ a pamˇet’ pouˇzita jako parametr volán´ı write, signál se nepoˇsle, protoˇze write vr´ at´ı -1 a errno je nastaveno na EFAULT. • pˇri pouˇzit´ı MAP PRIVATE vid´ım na Solarisu vˇsechny zmˇeny provedené jin´ ymi procesy, které namapovaly sd´ılenˇe, aˇz do té doby, kdy do stránky zap´ıˇsu

139

– v tom okamˇziku se vytvoˇr´ı kopie stránky a dalˇs´ı takové zmˇeny jiˇz nevid´ım. Na FreeBSD tyto zmˇeny nevid´ım ani pˇred zápisem. Viz specifikace: ,,It is unspecified whether modifications to the underlying object done after the MAP PRIVATE mapping is established are visible through the MAP PRIVATE mapping.” • hodnota off+len m˚ uˇze pˇrekraˇcovat aktuáln´ı velikost souboru, za konec souboru ale nelze zapisovat a soubor tak prodlouˇzit - proces by obdrˇzel signál SIGBUS resp. SIGSEGV, viz pˇr´ıklad mmap/lseek.c . Signál dostanu stejnˇe tak v situaci, kdy do read-only namapovaného segmentu zkus´ım zapsat (je to logické, pˇriˇrazen´ı nem´ a n´ avratovou hodnotu kterou byste mohli otestovat). • mapuje se vˇzdy po cel´ ych stránkách, hodnoty off (a pˇri MAP FIXED i addr) mus´ı b´ yt spr´ avnˇe zarovnané. Posledn´ı stránka je za koncem souboru doplnˇena nulami a tento u ´sek se nikdy nepˇrepisuje do souboru. • Anonymn´ı mapov´ an´ı lze sd´ılet mezi r˚ uzn´ ymi procesy pouze pomoc´ı fork(). Jedinou alternativou je pamˇet’ sd´ılená pomoc´ı systémového volán´ı shmat. • pˇr´ıstup do namapovaného u ´seku, ale za posledn´ı existuj´ıc´ı stránku namapovaného objektu, zp˚ usob´ı signál SIGBUS resp. SIGSEGV. Neplat´ı to vˇsude u ´plnˇe pˇresnˇe, viz pˇr´ıklad mmap/sigbus.c . • Pˇri pouˇzit´ı MAP FIXED namapován´ı souboru nahrad´ı pˇr´ıpadné pˇredchoz´ı mapov´ an´ı str´ anek v rozsahu. addr aˇz addr+len-1, viz pˇr´ıklad mmap/override.c . • existuj´ıc´ı rozˇs´ıˇren´ı pro flagy (nejsou souˇcást´ı SUSv3): – pˇr´ıznak MAP ANON ve FreeBSD a Solarisu – vytvoˇren´ı anonymn´ıho segmentu bez vazby na soubor, deskriptor mus´ı b´ yt -1. Mapuje se tak anonymn´ı objekt, kter´ y jak v´ıme má m´ısto fyzického uloˇzen´ı na swapu (tedy nen´ı trvalé). Linux m´ a podobnou funkcionalitu pˇres MAP ANONYMOUS. Tento pˇr´ıznak pouˇz´ıvaj´ı pamˇet’ové alokátory, které pracuj´ı s volán´ım mmap, viz také strana 124. – v IRIXu lze pomoc´ı MAP AUTOGROW automaticky zvˇetˇsit namapovan´ y objekt pˇri pˇr´ıstupu za jeho stávaj´ıc´ı konec. • bˇeˇzn´ ym pˇr´ıkazem, kter´ y pouˇz´ıvá mapován´ı soubor˚ u do pamˇeti, je cat(1). ˇ ıst z takové pamˇeti je prostˇe rychlejˇs´ı neˇz opakovanˇe volat read, kde je C´ nutné se pro kaˇzdé takové volán´ı pˇrepnout z uˇzivatelského reˇzimu do reˇzimu j´ adra a zpˇet.

140

Mapov´ an´ı soubor˚ u do pamˇ eti (2) int msync(void *addr, size t len, int flags ); • zap´ıˇse zmˇenˇené str´ anky v u ´seku len bajt˚ u od adresy addr do souboru. Hodnota flags je OR-kombinace – MS ASYNC . . . asynchronn´ı zápis – MS SYNC . . . synchronn´ı zápis – MS INVALIDATE . . . zruˇsit namapovaná data, která se liˇs´ı od obsahu souboru int munmap(void *addr, size t len ); • zap´ıˇse zmˇeny, zruˇs´ı mapován´ı v délce len od adresy addr. int mprotect(void *addr, size t len, int prot ); • zmˇen´ı pˇr´ıstupov´ a pr´ ava k namapovanému u ´seku souboru. Hodnoty prot jsou stejné jako u mmap().

• uloˇzen´ı zmˇen do souboru na disk je zaruˇcené aˇz po proveden´ı msync nebo munmap, ale ostatn´ı procesy, které maj´ı soubor namapován, vid´ı zmˇeny hned. • mapov´ an´ı pamˇeti a nastavován´ı pˇr´ıstupov´ ych práv pouˇz´ıvá napˇr. knihovna Electric Fence, kter´ a slouˇz´ı pro ladˇen´ı chyb pˇri práci s dynamickou pamˇet´ı.

141

Pˇ r´ıklad: mapov´ an´ı soubor˚ u do pamˇ eti int main(int argc, char *argv[]) { int fd, fsz; char *addr, *p1, *p2, c; fd = open(argv[1], O RDWR); fsz = lseek(fd, 0, SEEK END); p1 = addr = mmap(0, fsz, PROT READ|PROT WRITE, MAP SHARED, fd, 0); p2 = p1 + fsz - 1; while(p1
• Tento program otoˇc´ı poˇrad´ı znak˚ u v souboru (zap´ıˇse soubor od konce k zaˇc´ atku). • Jedna z hlavn´ıch v´ yhod sd´ılen´ ych segment˚ u je moˇznost pracovat s daty v souboru pomoc´ı pointerové aritmetiky. Obecnˇe je ale nutné dát pozor na zarovn´ an´ı pˇri dereferenc´ıch; napˇr. na SPARCu dojde pˇri takovém pˇr´ıstupu sign´ al SIGBUS, viz pˇr´ıklad mmap/aligned.c .

142

Dynamick´ y pˇ r´ıstup ke knihovn´ am void *dlopen(const char *file, int mode ); • zpˇr´ıstupn´ı knihovnu v souboru file, vrát´ı handle nebo NULL. • v mode je OR-kombinace RTLD NOW (okamˇzité relokace), RTLD LAZY (odloˇzené relokace), RTLD GLOBAL (symboly budou glob´ alnˇe dostupné), RTLD LOCAL (nebudou globálnˇe dostupné). void *dlsym(void *handle, const char *name ); • vr´ at´ı adresu symbolu zadaného jména z knihovny. int dlclose(void *handle ); • ukonˇc´ı pˇr´ıstup ke knihovnˇe. char *dlerror(void); • vr´ at´ı textov´ y popis chyby pˇri práci s knihovnami.

• pomoc´ı tˇechto funkc´ı lze implementovat dynamicky nahrávané plug-in moduly naˇc´ıtané aplikac´ı podle potˇreby (napˇr. podle obsahu jej´ıho konfiguraˇcn´ıho souboru). • dynamick´ ym naˇc´ıt´ an´ım knihoven se také dá vyˇreˇsit situace, kdy potˇrebujeme vyuˇz´ıt nˇekolik knihoven, které definuj´ı symbol se stejn´ ym jménem. Jedna knihovna se pˇr´ımo pˇrilinkuje k programu, k ostatn´ım se pˇristupuje pomoc´ı dlopen. • soubor mus´ı b´ yt ve spr´ avném formátu (sd´ılená knihovna .so ve formátu ELF resp. form´ atu podporovaném na daném systému), napˇr´ıklad u gcc to znamen´ a pouˇz´ıt pˇrep´ınaˇc -shared, u cc na Solarisu (Sun Studio Compiler) je to pˇrep´ınaˇc -G. Na OS X (s formátem Mach-O) je to -dynamiclib, knihovny maj´ı pˇr´ıponu .dynlib. • pokud cesta obsahuje znak /, bere se podle tvaru jako globáln´ı nebo relativn´ı. Pokud lom´ıtko neobsahuje, pouˇzije se pro hledan´ı objektu defaultn´ı nastaven´ı dynamického linkeru, typicky /lib a /usr/lib, které se dá rozˇs´ıˇr´ıt pomoc´ı promˇenné LD LIBRARY PATH. Na jej´ı pouˇzit´ı ovˇsem pozor, viz poznámky na stranˇe 37. • konstanty pro parametr mode funkce dlopen: – RTLD NOW – vˇsechny relokace (vyˇreˇsen´ı vˇsech odkaz˚ u) pro symboly nalezené v pˇripojovaném objektu jsou provedeny okamˇzitˇe po nataˇzen´ı knihovny, aplikace m´ a jistotu, ˇze jsou vˇsechny symboly pˇr´ıstupné

143

– RTLD LAZY – relokace mohou b´ yt odloˇzeny aˇz do chv´ıle pouˇzit´ı symbolu. Co to v praxi znamená? Pokud otevˇrete objekt, kter´ y závis´ı na dalˇs´ıch objektech, dynamick´ y linker tyto ostatn´ı závislé objekty mapuje do pamˇeti, aˇz kdyˇz jsou opravdu potˇreba. M˚ uˇze se tak stát, ˇze z´ avislosti neexistuj´ı, ale volán´ı dlopen stejnˇe uspˇeje. U RTLD NOW se z´ avislé objekty mapuj´ı do pamˇeti hned, a teprve pak dlopen vrát´ı pˇr´ısluˇsn´ y handle. Na Solarisu m˚ uˇzete defaultn´ı chován´ı pro dynamick´ y linker vynutit promˇenn´ ymi prostˇred´ı LD BIND NOW a LD BIND LAZY. Pˇri konfliktu nastaven´ı m´ a vˇzdy pˇrednost nastaven´ı NOW, at’ jiˇz je globáln´ı nebo jen v m´ odu vol´ an´ı dlopen pˇri mapován´ı jednoho konkrétn´ıho objektu. Pˇri spouˇstˇen´ı aplikace jsou vˇsechny závislé objekty defaultnˇe mapované hned, ale je moˇzné jednotlivé knihovny linkovat pro ,,lazy binding” pomoc´ı -z lazyload, viz manuálové stránky pro ld a ld.so.1. Pˇr´ıklad: dyn-lib/ld-lazy.c . – RTLD GLOBAL . . . symboly z knihovny mohou b´ yt pouˇzity pˇri zpracován´ı relokac´ı v ostatn´ıch knihovnách a jsou dostupné pomoc´ı dlopen(0, RTLD GLOBAL). Toto je defaultn´ı nastaven´ı pro objekty mapované pˇri spuˇstˇen´ı programu. Pro dlopen je defaultn´ı nastaven´ı RTLD LOCAL. To znamen´ a, ˇze je moˇzné namapovat stejnou knihovnu nˇekolikrát a symboly se nebudou vz´ ajemnˇe pˇrekr´ yvat. Pozor ale na to, kdyˇz takové knihovny budou pouˇz´ıvat symboly jiného globáln´ı objektu - napˇr. errno z libc.so. Takov´ y symbol je dále spoleˇcn´ y pro vˇsechny namapované objekty, vˇcetnˇe tˇech mapovan´ ych pomoc´ı RTLD LOCAL. • speci´ aln´ı handle RTLD NEXT hledá symbol pouze v knihovnách nahran´ ych po knihovnˇe, ve které je vol´ an´ı dlsym. Hod´ı se pro pˇredefinován´ı existuj´ıc´ıch funkc´ı, pokud v redefinované funkci potˇrebujeme volat p˚ uvodn´ı. Knihovna s novou funkc´ı se nahr´ av´ a jako prvn´ı (napˇr. pomoc´ı promˇenné LD PRELOAD), adresu p˚ uvodn´ı funkce z´ısk´ a volán´ım dlsym(RTLD NEXT, fn name ). Pˇr´ıklad: dyn-lib/rtld next.c . • vˇsechny tyto funkce jsou souˇcást´ı dynamického linkeru, kter´ y má kaˇzdá dynamicky slinkovan´ a aplikace namapovan´ y ve svém adresovém prostoru. Viz také strany 36 a 137.

144

Pˇ r´ıklad: zpˇ r´ıstupnˇ en´ı knihovny int err; void *handle; double y, x = 1.3; double (*fun)(double); char *libname = "libm.so", *fn name = "sin"; if ((handle = dlopen(libname, RTLD NOW)) == NULL) { fprintf(stderr, "%s\n", dlerror()); exit(1); } fun = dlsym(handle, fn name); if ((err = dlerror()) != NULL) fprintf(stderr, "%s\n", err); exit(1); y = fun(x); dlclose(handle);

• zde se vol´ a funkce sin z knihovny matematick´ ych funkc´ı libm.so. • funkce dlsym vr´ at´ı adresu symbolu daného jména, ale vˇzdy jako ukazatel na void, neprob´ıh´ a ˇz´ adn´ a typová kontrola ani nen´ı k dispozici ˇzádná informace o typu symbolu. Ten, kdo tuto adresu pouˇz´ıvá, mus´ı zajistit jej´ı správné pˇretypov´ an´ı. • pˇri pouˇzit´ı knihoven v C++ je tˇreba si uvˇedomit, ˇze C++ pouˇz´ıvá name mangling, tj. do jména funkce (metody) je zakódováno pˇr´ıpadné jméno tˇr´ıdy nebo namespace a typy parametr˚ u. • pˇr´ıklad: dyn-lib/dlopen.c

145


Sign´ aly • informuj´ı proces o v´ yskytu urˇcité události • na uˇzivatelské u ´rovni zpˇr´ıstupˇ nuj´ı mechanizmy pˇreruˇsen´ı • kategorie sign´ al˚ u: – chybov´ e ud´ alosti generované bˇeˇz´ıc´ım procesem, napˇr. pokus o pˇr´ıstup mimo pˇridˇelenou oblast pamˇeti (SIGSEGV) – asynchronn´ı ud´ alosti vznikaj´ıc´ı mimo proces, napˇr. signál od jiného procesu, vyprˇsen´ı nastaveného ˇcasu (SIGALRM), odpojen´ı termin´ alu (SIGHUP), stisk Ctrl-C (SIGINT) • nejjednoduˇsˇs´ı mechanizmus pro komunikaci mezi procesy – nesou pouze informaci o tom, ˇze nastala nˇejaká událost. • zpracov´ avaj´ı se asynchronnˇe – pˇr´ıchod signálu pˇreruˇs´ı bˇeh procesu a vyvol´ a se obsluˇzná funkce, tzv. handler sign´ alu

146

• se sign´ alem nen´ı sv´ az´ ana ˇz´ adná jiná informace neˇz ˇc´ıslo signálu, pokud se nepouˇzije POSIX-1003.1b rozˇs´ıˇren´ı (real-time), viz strana 161. • po n´ avratu z handleru (pokud k nˇemu dojde) proces pokraˇcuje od m´ısta pˇreruˇsen´ı. • historicky sign´ aly vznikly jako mechanizmus pro ,,násilné” ukonˇcen´ı procesu. Z toho vyplynul i n´ azev funkce kill pro poslán´ı signálu.

Posl´ an´ı sign´ alu int kill(pid t pid, int sig ); • poˇsle sign´ al s ˇc´ıslem sig procesu (nebo skupinˇe proces˚ u) podle hodnoty pid: – > 0 . . . procesu s ˇc´ıslem pid – == 0 . . . vˇsem proces˚ um ve stejné skupinˇe – == -1 . . . vˇsem proces˚ um, kromˇe systémov´ ych – < -1 . . . proces˚ um ve skupinˇe abs(pid) • sig == 0 znamen´ a, ˇze se pouze zkontroluje oprávnˇen´ı poslat sign´ al, ale ˇz´ adn´ y sign´ al se nepoˇsle. • pr´ avo procesu poslat signál jinému procesu závis´ı na UID obou proces˚ u.

• proces s EUID == 0 m˚ uˇze poslat signál libovolnému procesu. • ostatn´ı procesy: – Linux, Solaris: RUID nebo EUID procesu, kter´ y poslal signál, se mus´ı shodovat s re´ aln´ ym UID nebo saved set-user-ID c´ılového procesu. – FreeBSD: mus´ı se shodovat EUID obou proces˚ u. – IRIX: RUID nebo EUID procesu, kter´ y poslal signál, se mus´ı shodovat s re´ aln´ ym nebo efektivn´ım UID nebo saved set-user-ID c´ılového procesu. • pˇr´ıklad (obsahuje i zachycen´ı signálu, viz dalˇs´ı slajdy): signals/killme.c

147

Oˇ setˇ ren´ı sign´ al˚ u • pokud proces neˇrekne jinak, provede se v závislosti na konkrétn´ım sign´ alu implicitn´ı akce, tj. bud’: – ukonˇcen´ı procesu (exit) – ukonˇcen´ı procesu plus coredump (core) – ignorov´ an´ı sign´ alu (ignore) – pozastaven´ı procesu (stop) – pokraˇcov´ an´ı pozastaveného procesu (continue) • proces také m˚ uˇze nastavit ignorován´ı signálu • nebo sign´ al oˇsetˇren´ı uˇzivatelsky definovanou funkc´ı (handler), po n´ avratu z handleru proces pokraˇcuje od m´ısta pˇreruˇsen´ı sign´ aly SIGKILL a SIGSTOP vˇzdy vyvolaj´ı implicitn´ı akci (zruˇsen´ı, resp. pozastaven´ı).

• vytvoˇren´ı core dumpu znamená uloˇzen´ı kompletn´ıho obsahu pamˇeti procesu do souboru, typicky se jménem core • vˇetˇsina sign´ al˚ u implicitnˇe ukonˇc´ı proces, nˇekteré nav´ıc vytvoˇr´ı jiˇz zmiˇ novan´ y core dump, kter´ y je moˇzné následnˇe pouˇz´ıt pro ladic´ı u ´ˇcely. • d˚ uvod toho, proˇc pˇri exec se vˇsechny nastavené handlery signál˚ u nahrad´ı implicitn´ı obsluhou (strana 137) je jasn´ y – kód pˇr´ısluˇsn´ ych obluˇzn´ ych funkc´ı po vol´ an´ı exec pˇrestane existovat.

148

Pˇ rehled sign´ al˚ u (1) sign´ aly je moˇzné logicky rozdˇelit do nˇekolika skupin. . . detekovan´ e chyby: SIGBUS

pˇr´ıstup k nedef. ˇcásti pamˇet’ového objektu (core)

SIGFPE

chyba aritmetiky v pohyblivé ˇcárce (core)

SIGILL

nepovolen´ a instrukce (core)

SIGPIPE

z´ apis do roury, kterou nikdo neˇcte (exit)

SIGSEGV

pouˇzit´ı nepovolené adresy v pamˇeti (core)

SIGSYS

chybné systémové volán´ı (core)

SIGXCPU

pˇrekroˇcen´ı ˇcasového limitu CPU (core)

SIGXFSZ

pˇrekroˇcen´ı limitu velikosti souboru (core)

• Generov´ an´ı tˇechto sign´ al˚ u vycház´ı z chyb programu. • Pro sign´ aly SIGBUS, SIGFPE, SIGILL a SIGSEGV nen´ı normou pˇresnˇe definov´ ana pˇr´ıˇcina, ale obvykle jsou to chyby detekované hardwarem. • Pro tyto ˇ ctyˇ ri sign´ aly tak´ e plat´ı tato speci´ aln´ı pravidla (podrobnosti viz kapitola 2.4 Signal Concepts v normˇe SUSv3): – Pokud byly nastavené jako ignorované volán´ım sigaction, je chován´ı programu po té, co je mu takov´ y signál poslán, normou nedefinováno. – N´ avratov´ a hodnova handleru je nedefinována. – N´ asledek situace, kdy jeden z tˇechto signálu je maskován v okamˇziku jeho vygenerovan´ı je nedefinovan´ y. • Jin´ ymi slovy – pokud je hardwarem detekovaná chyba reálná (signál nen´ı posl´ an pˇres kill a podobn´ ymi funkcemi), váˇs program se pˇres tuto chybu nemus´ı v˚ ubec dostat. Nen´ı bezpeˇcné chybu ignorovat, pokraˇcovat v bˇehu po n´ avratu z handleru nebo oddálit ˇreˇsen´ı pomoc´ı zamaskován´ı. Zachytit tyto sign´ aly lze, o tom, ˇze by to bylo jinak, norma nemluv´ı. Pokud tedy máte pro tyto sign´ aly handler, je potˇ reba poˇ reˇ sit danou situaci jak uzn´ ate za vhodn´ e a pak ukonˇ cit program. M˚ uˇzete to vyzkouˇset na pˇr´ıkladu signals/catch-SIGSEGV.c . Dalˇs´ı informace vˇcetnˇe jiného pˇr´ıkladu na vyzkouˇsen´ı je moˇzné nalézt na stranˇe 231. • Pozn´ amka: pokud je nˇeco normou nedefinováno (undefined ), obecnˇe to znamen´ a, ˇze se neoˇcek´ av´ a, ˇze by programátor potˇreboval znát pˇresné chován´ı v

149

takové situaci. Pokud je to potˇreba, pravdˇepodobnˇe je ve vaˇsem programu nˇeco ˇspatnˇe. Jako vˇzdy, urˇcite by se naˇsly vyj´ımky potvrzuj´ıc´ı pravidlo.

Pˇ rehled sign´ al˚ u (2) generovan´ e uˇ zivatelem nebo aplikac´ı: SIGABRT

ukonˇcen´ı procesu (core)

SIGHUP

odpojen´ı terminálu (exit)

SIGINT

stisk speci´ aln´ı klávesy Ctrl-C (exit)

SIGKILL

zruˇsen´ı procesu (exit, nelze oˇ setˇ rit ani ignorovat)

SIGQUIT

stisk speci´ aln´ı klávesy Ctrl-\ (core)

SIGTERM

zruˇsen´ı procesu (exit)

SIGUSR1

uˇzivatelsky definovan´ y signál 1 (exit)

SIGUSR2

uˇzivatelsky definovan´ y signál 2 (exit)

• sign´ al SIGHUP se ˇcasto pouˇz´ıvá jako zp˚ usob, jak oznámit bˇeˇz´ıc´ımu démonu, ˇze se zmˇenil jeho konfiguraˇcn´ı soubor a má si ho proto znovu naˇc´ıst. • SIGINT a SIGQUIT jsou obvykle generovány z terminálu (Ctrl-C a Ctrl-\) a lze je pˇredefinovat pˇr´ıkazem stty nebo pomoc´ı funkce tcsetattr. Pro to aby se mohl vygenerovat core file je zapotˇreb´ı m´ıt to povolené v systémové konfiguraci a limitech, v shellu se toho dosáhne pˇr´ıkazem ulimit. • vzhledem k tomu, ˇze SIGKILL nelze zachytit, jej pouˇz´ıvejte jen v nutn´ ych pˇr´ıpadech; typick´ ym pˇr´ıpadem je to, ˇze bˇeˇz´ıc´ı proces jiˇz nelze ukonˇcit jin´ ym sign´ alem. Mnoho aplikac´ı, hlavnˇe démon˚ u, spoléhá na to, ˇze vynucené ukonˇcen´ı sign´ alem je pˇres SIGTERM. Tento signál si zachyt´ı a provede ukonˇcovac´ı operace – napˇr´ıklad uloˇzen´ı aktuáln´ı databáze na disk, smazán´ı doˇcasn´ ych soubor˚ u apod. Pouˇz´ıvat rovnou SIGKILL proto, ˇze proces to “vˇzdycky zabije”, je neznalost vˇeci, kter´ a se v´ am m˚ uˇze dost vymst´ıt. • uk´ azka na SIGQUIT na Solarisu: $ sleep 10 ^\Quit (core dumped) $ mdb core Loading modules: [ libc.so.1 ld.so.1 ] > $c libc.so.1‘__nanosleep+0x15(8047900, 8047908) 150

libc.so.1‘sleep+0x35(a) main+0xbc(2, 8047970, 804797c) _start+0x7a(2, 8047a74, 8047a7a, 0, 8047a7d, 8047b91) > • SIGTERM je defaultn´ı sign´ al pro pˇr´ıkaz kill(1) • SIGUSR1 a SIGUSR2 nejsou pouˇzity ˇzádn´ ym systémov´ ym volán´ım a jsou plnˇe k dispozici uˇzivateli • zaj´ımavost: FreeBSD 5.3 obsahuje chybu, která dovol´ı za jist´ ych okolnost´ı zachytit sign´ al SIGKILL. Pˇr´ıklad: signals/catch-SIGKILL.c .

Pˇ rehled sign´ al˚ u (3) job control: SIGCHLD

zmˇena stavu synovského procesu (ignore)

SIGCONT

pokraˇcov´ an´ı pozastaveného procesu (continue)

SIGSTOP

pozastaven´ı (stop, nelze oˇ setˇ rit ani ignorovat)

SIGTSTP

pozastaven´ı z terminálu Ctrl-Z (stop)

SIGTTIN

ˇcten´ı z termin´ alu procesem na pozad´ı (stop)

SIGTTOU

z´ apis na terminál procesem na pozad´ı (stop)

• souˇc´ ast´ı nepovinného POSIX rozˇs´ıˇren´ı, existuj´ı pouze kdyˇz v je definov´ ano makro POSIX JOB CONTROL

• plat´ı, ˇze nikdy nen´ı povoleno v´ıce proces˚ um najednou ˇc´ıst z kontroln´ıho termin´ alu, ale v´ıce proces˚ u najednou m˚ uˇze na terminál zapisovat. • pozastaven´ı skupiny proces˚ u spustˇené z terminálu (ˇcasto pˇres Ctrl-Z) se prov´ ad´ı sign´ alem SIGTSTP, ne SIGSTOP; aplikace tedy tento signál m˚ uˇze zachytit.

151

Pˇ rehled sign´ al˚ u (4) ˇ casovaˇ ce: SIGALRM

pl´ anované ˇcasové pˇreruˇsen´ı (exit)

SIGPROF

vyprˇsen´ı profiluj´ıc´ıho ˇcasovaˇce (exit)

SIGVTALRM

vyprˇsen´ı virtuáln´ıho ˇcasovaˇce (exit)

r˚ uzn´ e: SIGPOLL

testovateln´ a událost (exit)

SIGTRAP

ladic´ı pˇreruˇsen´ı (core)

SIGURG

urgentn´ı ud´ alost na soketu (ignore)

• SIGALRM a souvisej´ıc´ı funkce alarm se pouˇz´ıvaj´ı pro odmˇeˇrován´ı ˇcasov´ ych interval˚ u v uˇzivatelském procesu (napˇr. pˇri implementaci timeout˚ u).

152

Nastaven´ı obsluhy sign´ al˚ u int sigaction(int sig, const struct sigaction *act, struct sigaction *oact ); • nastav´ı obsluhu sign´ alu sig podle act a vrát´ı pˇredchoz´ı nastaven´ı v oact. • obsah struktury sigaction: – void (*sa handler )(int) . . . SIG DFL, SIG IGN, nebo adresa handleru – sigset t sa mask . . . signály blokované v handleru, nav´ıc je blokov´ an sign´ al sig – int sa flags . . . SA RESETHAND (pˇri vstupu do handleru nastavit SIG DFL), SA RESTART (restartovat pˇreruˇsená systémov´ a vol´ an´ı), SA NODEFER (neblokovat signál sig bˇehem obsluhy)

• kdyˇz je act == NULL, pouze se zjist´ı nastaven´ı obsluhy, nemˇen´ı se. Jestliˇze n´ as pˇredchoz´ı nastaven´ı nezaj´ımá, lze pouˇz´ıt oact == NULL. • pokud nen´ı nastaveno SA RESTART, systémová volán´ı aktivn´ı v bodˇe pˇr´ıchodu sign´ alu skonˇc´ı s chybou EINTR. Restartován´ı nemus´ı fungovat pro vˇsechna systémov´ a vol´ an´ı, napˇr. na FreeBSD je select pˇreruˇsen signálem vˇzdy, i kdyˇz je nastaveno SA RESTART (pozn: nemus´ı b´ yt pravda u souˇcasn´ ych verz´ı, nezkouˇsel jsem to na nich). • pozor na problém vz´ ajemného vylouˇcen´ı mezi procesem a handlerem, popˇr. mezi handlery pro r˚ uzné signály. Jestliˇze je nastaveno SA NODEFER, mˇel by b´ yt handler reentrantn´ı. • v handleru sign´ alu by se mˇ ely pouˇ z´ıvat pouze funkce, kter´ e jsou pro takov´ e pouˇ zit´ı bezpeˇ cn´ e. Mus´ı bud’ b´ yt reentrantn´ı, nebo je nutné zajistit, aby nepˇriˇsel sign´ al v nevhodnou dobu (napˇr. uvnitˇr funkce pˇrijde sign´ al, v jehoˇz handleru se volá stejná funkce). Minimáln´ı skupina funkc´ı, které mus´ı b´ yt tzv. async-signal-safe, je vyjmenována v SUSv3 v sekci System Interfaces: General Information ⇒ Signal Concepts ⇒ Signal Actions (2.4.3). Jednotlivé systémy mohou samozˇrejmˇe definovat i dalˇs´ı takové funkce. Zda funkce je nebo nen´ı bezpeˇcnˇe pouˇzitelná v handleru by mˇelo b´ yt jasné z manu´ alové str´ anky; na Solarisu je tato informace vˇzdy v sekci ATTRIBUTES. • proˇc m˚ uˇze nastat problém, kdyˇz pouˇzijete v handleru signálu jinou funkci neˇz async-signal-safe? Je to jednoduché – pˇredstavte si, ˇze kdyˇz program vykon´ av´ a funkci, kter´ a nen´ı async-signal-safe, pˇrijde signál a v handleru se 153

vyvol´ a funkce stejn´ a. Pokud funkce nen´ı pro takové pouˇzit´ı napsaná, tak m˚ uˇze doj´ıt napˇr´ıklad k nekonzistenci statick´ ych dat ve funkci pouˇzit´ ych, pˇr´ıpadnˇe k uv´ aznut´ı (dead lock) apod. Právˇe kv˚ uli tomu, ˇze v handlerech lze bezpeˇcnˇe pouˇz´ıt jen podmnoˇzinu existuj´ıc´ıch volán´ı, se v handleru ˇcasto pouze nastav´ı glob´ aln´ı promˇenná oznaˇcuj´ıc´ı pˇr´ıchod pˇr´ısluˇsného signálu a ta se n´ aslednˇe testuje, napˇr´ıklad v cyklu serveru, kter´ y vyˇrizuje poˇzadavky. Zpomalen´ı obsluhy sign´ alu je minimáln´ı, protoˇze funkce která ˇceká na dalˇs´ı poˇzadavek je typicky pˇreruˇsitelná signálem a v takovém pˇr´ıpadˇe ihned vrac´ı EINTR. N´ asleduje kontrola globáln´ı(ch) promˇenné(´ ych) na to, zda byl pˇrijmut nˇejak´ y sign´ al. • funkce sigaction je obecnˇejˇs´ı neˇz starˇs´ı funkce signal a sigset, které zde ani nezmiˇ nuji. Doporuˇcuji pouˇz´ıvat pouze sigaction. Pouˇzit´ı signal nen´ı napˇr´ıklad spr´ avné s vl´ akny, viz specifikace: “Use of this function is unspecified in a multi-threaded process.” • Pozor na to, ˇze chov´ an´ı funkce signal() se m˚ uˇze liˇsit podle systému. Napˇr´ıklad na FreeBSD z˚ ust´ av´ a handler stále nastaven, na Solarisu je z d˚ uvodu zachov´ an´ı zpˇetné kompatibility handler pˇred jeho vyvolán´ım resetován na SIG DFL. Funkce pˇr´ıznaku SA RESETHAND je právˇe to, aby bylo moˇzné simulovat p˚ uvodn´ı chov´ an´ı funkce signal(), které b´ yvá implementováno pomoc´ı systémového vol´ an´ı sigaction(). Pˇr´ıklad na rozd´ıl mezi funkcemi signal() a sigaction(): signal/signal-vs-sigaction.c . • (nebudete nejsp´ıˇs potˇrebovat) pro v´ yskok z handleru signálu jinam neˇz na m´ısto vzniku sign´ alu se daj´ı pouˇz´ıt funkce sigsetjmp a siglongjmp. Pozor na to, ˇze v tomto pˇr´ıpadˇe si mus´ıme b´ yt jisti, ˇze v okamˇziku pˇr´ıchodu signálu nen´ı program uvnitˇr ne-reentrantn´ı funkce. V´ yskokem z handleru do hlavn´ıho programu nen´ı vykon´ av´ an´ı takové funkce ukonˇceno a mohou nastat stejné problémy jako pˇri vol´ an´ı ne-reentrantn´ı funkce pˇr´ımo z handleru. • pokud systém podporuje ˇc´ ast POSIX.1b zvanou Realtime Signals Extension (RTS), je moˇzné pˇr´ıznakem SA SIGINFO toto rozˇs´ıˇren´ı pouˇz´ıt. V tom pˇr´ıpadˇe se pouˇzije jin´ a poloˇzka struktury sigaction pro ukazatel na handler, a tou je sa sigaction. Tento handler má jiˇz 3 parametry a je moˇzné zjistit napˇr´ıklad to, kter´ y proces signál poslal, pod jak´ ym uˇzivatelem proces bˇeˇzel a mnoho dalˇs´ıch informac´ı. Zájemce odkazuji na manuálovou stránku signal.h(3HEAD) na Solarisu, specifikaci tohoto hlaviˇckového souboru pˇr´ımo v SUSv3 nebo na knihu [POSIX.4], strana 5. Dalˇs´ı informace jsou také na stran´ ach 16 a 165. Pˇr´ıklady: signals/siginfo.c , signals/sigqueue.c .

154

Pˇ r´ıklad: ˇ casovˇ e omezen´ y vstup void handler(int sig) { write(2," !!! TIMEOUT !!! \n", 17); } int main(void) { char buf[1024]; struct sigaction act; int sz; act.sa handler = handler; sigemptyset(&act.sa mask); act.sa flags = 0; sigaction(SIGALRM, &act, NULL); alarm(5); sz = read(0, buf, 1024); if (sz > 0) write(1, buf, sz); return (0); }

• lze pouˇz´ıvat i ˇcasovaˇce s jemnˇejˇs´ım rozliˇsen´ım neˇz 1 s. Nastavuj´ı a testuj´ı se funkcemi setitimer a getitimer. Pˇri vyprˇsen´ı pos´ılaj´ı signály procesu, kter´ y ˇcasovaˇce nastavil: – ITIMER REAL . . . mˇeˇr´ı reáln´ y ˇcas, pos´ılá SIGALRM – ITIMER VIRTUAL . . . mˇeˇr´ı virtuáln´ı ˇcas (pouze ˇcas, kdy proces bˇeˇz´ı), pos´ıl´ a SIGVTALRM – ITIMER PROF . . . mˇeˇr´ı virtuáln´ı ˇcas a ˇcas, kdy systém bˇeˇz´ı na konto procesu, pos´ıl´ a SIGPROF • pozn: vˇsimˇete si, ˇze aˇckoliv by to svádˇelo pouˇz´ıt pro tisk hláˇsky v pˇr´ıkladu funkci fprintf apod., nemusel by to b´ yt dobr´ y nápad, protoˇze nemus´ı b´ yt bezpeˇcn´ a pro pouˇzit´ı v handleru signálu, viz strana 160. • pˇr´ıklad: signals/alarm.c

155

Blokov´ an´ı sign´ al˚ u • blokované sign´ aly budou procesu doruˇceny a zpracovány aˇz po odblokov´ an´ı. int sigprocmask(int how, const sigset t *set, sigset t *oset ); • nastav´ı masku blokovan´ ych signál˚ u a vrát´ı starou masku. u co se maj´ı blokovat, pro • how – SIG BLOCK pro pˇridán´ı signál˚ odebr´ an´ı SIG UNBLOCK, pro kompletn´ı zmˇenu masky SIG SETMASK • pro manipulaci s maskou signál˚ u slouˇz´ı funkce: sigaddset(), sigdelset(), sigemptyset(), sigfillset(), sigismember() int sigpending(sigset t *set ); • vr´ at´ı ˇcekaj´ıc´ı zablokované signály.

• Je rozd´ıl mezi ignorov´ an´ım a blokován´ım signálu. Ignorovan´ y signál jádro zahod´ı a proces ho nedostane, blokovan´ y signál proces dostane po jeho odblokov´ an´ı. • Z´ avis´ı na implementaci, zda pˇri v´ıcenásobném doruˇcen´ı stejného signálu procesu, kter´ y m´ a tento sign´ al zablokovan´ y, bude signál po odblokován´ı oˇsetˇren jednou nebo v´ıcekr´ at. • V pˇr´ıpadˇe rozˇs´ıˇren´ı sign´ al˚ u z POSIX.4 (strana 161), tj. pouˇzit´ı pˇr´ıznaku SA SIGINFO, jsou sign´ aly doruˇcované pˇres frontu a tedy se ˇzádn´ y násobn´ y v´ yskyt stejného sign´ alu neztrat´ı. • Argument oset pro z´ısk´ an´ı p˚ uvodn´ı masky m˚ uˇze b´ yt NULL, stejnˇe jako m˚ uˇze b´ yt nastaven´ y na NULL i parametr druh´ y, tj. set. Ve speciáln´ım pˇr´ıpadˇe, kdy jsou oba parametry nulové, funkce sigprocmask nedˇelá nic.

156

Pˇ r´ıklad: blokov´ an´ı sign´ al˚ u sigset t sigs, osigs; structure sigaction sa; sigfillset(&sigs); sigprocmask(SIG BLOCK, &sigs, &osigs); switch(cpid = fork()) { case -1: /* Chyba */ sigprocmask(SIG SETMASK, &osigs, NULL); ... case 0: /* Synovsk´ y proces */ sa.sa handler = h cld; sigemptyset(&sa.sa mask); sa.sa flags = 0; sigaction(SIGINT, &sa, NULL); sigprocmask(SIG SETMASK, &osigs, NULL); ... default: /* Rodiˇ covsk´ y proces */ sigprocmask(SIG SETMASK, &osigs, NULL); ... }

• pˇr´ıklad ukazuje situaci, kdy proces vytváˇr´ı potomky pomoc´ı fork a je potˇreba, aby potomci mˇeli jin´ y handler signál˚ u neˇz rodiˇcovsk´ y proces. Funguje to proto, ˇze vol´ an´ı fork nemˇen´ı masky signál˚ u, viz strana 136. • pro jednoduchost v pˇr´ıkladu blokuji vˇsechny signály, i kdyˇz na stranách 156 a 231 je vysvˇetleno, proˇc to nen´ı správné pouˇzit´ı maskován´ı. • blokov´ an´ı je vhodné pouˇz´ıt tam, kde oˇsetˇren´ı pˇreruˇsen´ı uprostˇred posloupnosti operac´ı by bylo pˇr´ıliˇs sloˇzité, nebo kde korektn´ı oˇsetˇren´ı nen´ı jinak moˇzné. V uvedeném pˇr´ıkladˇe by bez blokován´ı signál˚ u mohl synovsk´ y proces dostat sign´ al dˇr´ıv, neˇz stihne zmˇenit handler. • dalˇs´ı pˇr´ıklad je proces, kter´ y pˇri vyprˇsen´ı timeoutu pˇreruˇs´ı provádˇenou posloupnost operac´ı vol´ an´ım siglongjmp zevnitˇr handleru signálu. Je potˇreba zablokovat sign´ al SIGALRM bˇehem provádˇen´ı atomick´ ych podposloupnost´ı (tj. takov´ ych, které se mus´ı provést bud’ celé, nebo v˚ ubec ne).

157

ˇ an´ı na sign´ Cek´ al int pause(void); • pozastav´ı volaj´ıc´ı proces do pˇr´ıchodu (nemaskovaného) signálu int sigsuspend(const sigset t *sigmask ); • jako pause(), ale nav´ıc po dobu ˇcekán´ı masku blokovan´ ych sign´ al˚ u zmˇen´ı na sigmask int sigwait(const sigset t *set, int *sig ); • ˇcek´ a na pˇr´ıchod sign´ alu z mnoˇziny set (tyto signály mus´ı b´ yt pˇredt´ım zablokované), ˇc´ıslo signálu vrát´ı v sig. Vrac´ı 0 nebo ˇc´ıslo chyby. • nevol´ a se handler sign´ alu (to ale nen´ı v normˇe jednoznaˇcnˇe definov´ ano)

• Nemaskovan´ y sign´ al v pause a sigsuspend vyvolá handler a po jeho skonˇcen´ı program opust´ı sign´ al zachycuj´ıc´ı funkci a pokraˇcuje dále. Pokud má ale sign´ al proces ukonˇcit (napˇr. nemaskovan´ y SIGTERM bez handleru), stane se tak. • Pomoc´ı tˇechto funkc´ı a blokován´ı signál˚ u se implementuje synchronn´ı obsluha sign´ al˚ u. Proces nejprve zablokuje signály, které ho zaj´ımaj´ı, a pak na nˇe ve vhodn´ ych chv´ıl´ıch bud’ ˇcek´ a, nebo jen testuje (pomoc´ı sigpending), zda sign´ al pˇriˇsel, a pokud ne, pokraˇcuje dál. • Funkce sigwait byla pˇrid´ ana s POSIX-1003.1c rozˇs´ıˇren´ım (vlákna) a je to “jedin´ y” spr´ avn´ y zp˚ usob, jak obsluhovat asynchronn´ı signály v multivl´ aknové aplikaci. To ˇze byla pˇridána s vlákny je potvrzeno i t´ım, ˇze v pˇr´ıpadˇe problém˚ u vrac´ı pˇr´ımo ˇc´ıslo chyby. • Je nutné d´ at pozor na to, ˇze existuj´ı i pˇr´ıbuzné podobnˇe se jmenuj´ıc´ı funkce sigwaitinfo a sigtimedwait, definované s rozˇs´ıˇren´ım POSIX-1003.1b (realtime). Funguj´ı na podobném principu, ale na rozd´ıl od sigwait pracuj´ı s errno a je z nich moˇzné z´ıskat v´ıce informac´ı d´ıky struktuˇre siginfo t, viz strana 161. Je tedy moˇzné je pouˇz´ıt m´ısto sigwait. • Pˇr´ıklad (sign´ al se pouˇzije pro synchronizaci dvou proces˚ u komunikuj´ıc´ıch pˇres sd´ılenou pamˇet’): signals/sigwait.c • Pozor na to, ˇze byste nemˇeli tento zp˚ usob obsluhy signál˚ u pouˇz´ıvat pro sign´ aly synchronn´ı jako jsou SIGSEGV, SIGILL, apod. V´ıce se doˇctete na stranách 156 a 231. 158


159

Probl´ em: konflikt pˇ ri sd´ılen´ı dat • m´ ame strukturu struct { int a, b; } shared ; • for( ; ; ) { /* neatomick´ a operace */ a = shared.a; b = shared.b; if (a != b) printf("NEKONZISTENTN´ I STAV"); /* neatomick´ a operace */ shared.a = val; shared.b = val; } • jestliˇze tento cyklus spust´ıme ve dvou r˚ uzn´ ych procesech (nebo vl´ aknech), které obˇe sd´ılej´ı stejnou strukturu shared a maj´ı r˚ uzné hodnoty val, bude docházet ke konflikt˚ um. • pˇr´ıˇcina: operace na zv´ yraznˇen´ ych ˇrádc´ıch nejsou atomické.

• ani operace, kterou lze v C zapsat jedn´ım pˇr´ıkazem, nemus´ı b´ yt atomická. Pˇr.: na RISCov´ ych procesorech se pˇr´ıkaz a++ typicky pˇreloˇz´ı jako sekvence: load reg,[a] inc reg store [a],reg a to z toho d˚ uvodu, ˇze na této architektuˇre nelze inkrementovat ˇc´ıslo pˇr´ımo v pamˇeti. Pro tyto pˇr´ıpady m´ a napˇr´ıklad Solaris sadu funkc´ı atomic add(3c), jejichˇz pouˇzit´ı je mnohem rychlejˇs´ı neˇz klasické zamykac´ı mechanismy. V´ıce viz strana 242. • obecnˇe obdobn´ y problém nastává, kdyˇz v´ıce proces˚ u sd´ıl´ı nˇejak´ y systémov´ y zdroj. • pˇr´ıklad: race/race.c

160

Sc´ en´ aˇ r konfliktu Procesy A(val==1) a B(val==2)

a

b

1.

poˇc´ ateˇcn´ı stav struktury

?

?

2.

proces A zap´ıˇse do poloˇzky a

1

?

3.

proces B zap´ıˇse do poloˇzky a

2

?

4.

proces B zap´ıˇse do poloˇzky b

2

2

5.

proces A zap´ıˇse do poloˇzky b

2

1

6.

struktura je v nekonzistentn´ım stavu a jeden z proces˚ u to zjist´ı.

• dalˇs´ı moˇznost: 1. struktura je v konzistentn´ım stavu, napˇr. (1, 1) 2. proces B zap´ıˇse 2 do poloˇzky a 3. proces A pˇreˇcte hodnotu struktury (2, 1) dˇr´ıve, neˇz proces B stihne zapsat poloˇzku b • pozor na to, ˇze synchronizaˇcn´ı problémy se ˇcasto projev´ı aˇz na v´ıceprocesorovém stroji, nebo na v´ıce procesorech neˇz kolik jich máte pˇri v´ yvoji k dispozici apod. Je tˇreba na to myslet pˇri testován´ı.

161

ˇ sen´ı: vz´ Reˇ ajemn´ e vylouˇ cen´ı proces˚ u • je potˇreba zajistit atomicitu operac´ı nad strukturou, tzn. jeden proces prov´ ad´ı modifikaci a dokud neuvede strukturu do konzistentn´ıho stavu, druh´ y proces s n´ı nem˚ uˇze manipulovat. Procesy A(val==1) a B(val==2)

a

b

poˇc´ ateˇcn´ı stav struktury

?

?

proces A zap´ıˇse do poloˇzky a

1

?

proces B mus´ı ˇcekat

1

?

proces A zap´ıˇse do poloˇzky b

1

1

proces B zap´ıˇse do poloˇzky a

2

1

6.

proces B zap´ıˇse do poloˇzky b

2

2

7.

Struktura je v konzistentn´ım stavu.

1.   2.   3.    4.   5. 

• je tˇreba zajistit vz´ ajemné vylouˇcen´ı i pˇri ˇcten´ı, aby ˇctouc´ı proces nepˇreˇcetl nekonzistentn´ı obsah struktury uprostˇred zmˇen. Pˇri zápisu je nutné vylouˇcit vˇsechny ostatn´ı procesy, ale pˇri ˇcten´ı staˇc´ı vylouˇcit jen zápis, souˇcasné ˇcten´ı v´ıce procesy nevad´ı. • kritick´ a sekce je kus k´ odu, kter´ y by mˇel provádˇet pouze jeden proces nebo vl´ akno, jinak m˚ uˇze doj´ıt k nekonzistenc´ım; napˇr´ıklad ˇspatnˇe pospojovan´ y v´ azan´ y seznam, neodpov´ıdaj´ıc´ı si indexy v databázi apod. Je moˇzné to definovat i tak, ˇze kritick´ a sekce je kód, kter´ y pˇristupuje k nebo modifikuje bl´ıˇze neurˇcen´ y zdroj sd´ılen´ y v´ıce procesy nebo vlákny a proto je nutné pˇr´ıstup k takovému k´ odu synchronizovat. Kritická sekce by mˇela b´ yt co nejkratˇs´ı, aby ostatn´ı procesy (vl´ akna) ˇz´ adaj´ıc´ı o vstup do této sekce ˇcekaly co nejkratˇs´ı moˇznou dobu. Druh´ a definice je o nˇeco obecnˇejˇs´ı, protoˇze se do n´ı vejdou i situace, kdy pouze jeden proces nebo vlákno m˚ uˇze stav mˇenit, ale pokud se tak nedˇeje, m˚ uˇze v´ıce proces˚ u ˇci vláken dan´ y stav ˇc´ıst, to znamená ˇze kód kritické sekce za jist´ ych pˇresnˇe definovan´ ych podm´ınek m˚ uˇze vykonávat v´ıce proces˚ u nebo vl´ aken najednou.

162

Probl´ em: konflikt zapisovatel˚ uaˇ cten´ aˇ r˚ u • nˇekolik bˇeˇz´ıc´ıch proces˚ u zapisuje protokol o své ˇcinnosti do spoleˇcného log-souboru. Nov´ y záznam je pˇripojen vˇzdy na konec souboru. • pokud z´ apis z´ aznamu nen´ı proveden atomickou operac´ı, m˚ uˇze doj´ıt k prom´ıch´ an´ı v´ıce souˇcasnˇe zapisovan´ ych záznam˚ u. • zapisovat sm´ı vˇzdy pouze jeden proces. • dalˇs´ı procesy ˇctou data z log-souboru. • pˇri pˇreˇcten´ı pr´ avˇe zapisovaného záznamu obdrˇz´ıme nesprávná (ne´ upln´ a) data. • bˇehem operace z´ apisu ze souboru nelze ˇc´ıst. Kdyˇz nikdo nezapisuje, m˚ uˇze v´ıce proces˚ u ˇc´ıst souˇcasnˇe.

• povoleny jsou tedy 2 situace: jeden zapisovatel nebo v´ıce ˇctenáˇr˚ u • na lok´ aln´ım disku lze pro synchronizaci zapisovatel˚ u pouˇz´ıt ˇreˇsen´ı pomoc´ı pˇr´ıznaku O APPEND, které ale nebude fungovat napˇr. na vzdáleném disku pˇr´ıstupném pˇres NFS nebo v pˇr´ıpadˇe, ˇze zápis jedné logovac´ı zprávy je proveden v´ıce neˇz jedn´ım vol´ an´ım write(). Nav´ıc to neˇreˇs´ı synchronizaci ˇctenáˇr˚ u – lze ˇc´ıst i v pr˚ ubˇehu z´ apisu.

163

ˇ sen´ı: zamyk´ Reˇ an´ı soubor˚ u • zapisuj´ıc´ı proces zamkne soubor pro zápis. Ostatn´ı procesy (zapisovatelé i ˇcten´ aˇri) se souborem nemohou pracovat a mus´ı ˇcekat na odemˇcen´ı z´ amku. • ˇctouc´ı proces zamkne soubor pro ˇcten´ı. Zapisovatelé mus´ı ˇcekat na odemˇcen´ı z´ amku, ale ostatn´ı ˇctenáˇri mohou také zamknout soubor pro ˇcten´ı a ˇc´ıst data. • v jednom okamˇziku m˚ uˇze b´ yt na souboru aktivn´ı nejv´ yˇse jeden z´ amek pro z´ apis nebo libovolnˇe mnoho zámk˚ u pro ˇcten´ı, ale ne oba typy z´ amk˚ u souˇcasnˇe. • z d˚ uvodu efektivity by kaˇzd´ y proces mˇel drˇzet zámek co nejkratˇs´ı dobu a pokud moˇzno nezamykat cel´ y soubor, ale jen u ´sek, se kter´ ym pracuje. Preferované je pasivn´ı ˇcekán´ı, aktivn´ı ˇcek´ an´ı je vhodné jen na velmi krátkou dobu.

• dva zp˚ usoby ˇcek´ an´ı: aktivn´ı (busy waiting) – proces v cyklu testuje podm´ınku, na kterou ˇceká, dokud nen´ı splnˇena pasivn´ı – proces se zaregistruje v jádru jako ˇcekaj´ıc´ı na podm´ınku a pak se usp´ı, j´ adro ho probud´ı, kdyˇz dojde ke splnˇen´ı podm´ınky • aktivn´ı ˇcek´ an´ı je ospravedlnitelné pouze ve speciáln´ıch situac´ıch. Na takové situace asi v z´ apoˇctovém programu nenaraz´ıte a urˇcitˇe ne v pˇr´ıkladu u zkouˇsky. Pouˇ zit´ı aktivn´ıho ˇ cek´ an´ı v takov´ em pˇ r´ıpadˇ e automaticky znamen´ a nesplnˇ en´ı zad´ an´ı p´ısemky.

164

Synchronizaˇ cn´ı mechanismy • teoretické ˇreˇsen´ı – algoritmy vzájemného vylouˇcen´ı (Dekker 1965, Peterson 1981) • z´ akaz pˇreruˇsen´ı (na 1 CPU stroji), speciáln´ı test-and-set instrukce • lock-soubory • n´ astroje poskytované operaˇcn´ım systémem – semafory (souˇc´ ast System V IPC) – z´ amky pro soubory (fcntl(), flock()) – synchronizace vl´ aken: mutexy (ohraniˇcuj´ı kritické sekce, pouze jedno vl´ akno m˚ uˇze drˇzet mutex), podm´ınkov´ e promˇ enn´ e (zablokuj´ı vlákno, dokud jiné vlákno nesignalizuje zmˇenu podm´ınky), read-write z´ amky (sd´ılené a exkluzivn´ı zámky, podobnˇe jako pro soubory)

• Dekker i Peterson potˇrebuj´ı k dosaˇzen´ı poˇzadavaného v´ ysledku pouze sd´ılenou pamˇ et’, tj. nˇekolik promˇenn´ ych sd´ılen´ ych obˇema procesy. • Dekkerovo ˇreˇsen´ı se ud´ av´ a jako prvn´ı ˇreˇsen´ı problému vzájemného vylouˇcen´ı dvou proces˚ u, aniˇz by bylo nutné aplikovat naivn´ı algoritmus striktn´ıho stˇr´ıd´ an´ı, tj. pokud druh´ y proces nevykazoval zájem o vstup do kritické sekce, mohl tam prvn´ı (a naopak) proces vstoupit tolikrát za sebou, kolikrát chtˇel. Dekkerovo ˇreˇsen´ı nen´ı v˚ ubec triviáln´ı, porovnejte s o 16 let mladˇs´ım ˇreˇsen´ım Petersonov´ ym, napˇr´ıklad na en.wikipedia.org (hledejte “Dekker’s algorithm”, “Peterson’s algorithm”) • my se nebudeme zab´ yvat teoretick´ ymi algoritmy vzájemného vylouˇcen´ı ani nebudeme popisovat hardwarové mechanismy pouˇz´ıvané jádrem. Zamˇeˇr´ıme se pouze na pouˇzit´ı lock soubor˚ u (které vyuˇz´ıvaj´ı atomiˇcnosti nˇekter´ ych souborov´ ych operac´ı) a speci´ aln´ıch synchronizaˇcn´ıch nástroj˚ u poskytovan´ ych j´ adrem. • podm´ınkové promˇenné = conditional variables

165

Lock-soubory • pro kaˇzd´ y sd´ılen´ y zdroj existuje dohodnuté jméno souboru. Zamˇcen´ı zdroje se provede vytvoˇren´ım souboru, odemˇcen´ı smaz´ an´ım souboru. Kaˇzd´ y proces mus´ı otestovat, zda soubor existuje, a pokud ano, tak poˇckat. void lock(char *lockfile) { while( (fd = open(lockfile, O RDWR|O CREAT|O EXCL, 0600)) == -1) ˇ ame ve smyˇcce na odemˇcen´ı */ sleep(1); /* Cek´ close(fd); } void unlock(char *lockfile) { unlink(lockfile); }

• kl´ıˇcem k u ´spˇechu je samozˇrejmˇe pouˇzit´ı flagu O EXCL ym • pˇr´ıklad: file-locking/lock-unlock.c , a pouˇzijte spoleˇcnˇe se shellov´ skriptem file-locking/run.sh . • pˇri hav´ arii procesu nedojde ke zruˇsen´ı pˇr´ıpadn´ ych zámk˚ u a ostatn´ı procesy by ˇcekaly vˇeˇcnˇe. Proto je vhodné si do lock-souboru poznamenat PID procesu, kter´ y z´ amek vytvoˇril. Proces, kter´ y ˇceká na odemˇcen´ı, m˚ uˇze testovat, zda proces, kterému z´ amek patˇr´ı, stále bˇeˇz´ı. Kdyˇz ne, lze zámek zruˇsit a znovu zkusit vytvoˇrit. User level pˇr´ıkaz kter´ y toto um´ı a dovoluje pouˇz´ıvat lock soubory z shellov´ ych skript˚ u je napˇr´ıklad shlock(1) (na FreeBSD v /usr/ports/sysutils/shlock), teoreticky by vˇsak mohl zp˚ usobit situaci z n´ asleduj´ıc´ıho odstavce. • pozor: jestliˇze v´ıce proces˚ u najednou zjist´ı, ˇze proces drˇz´ıc´ı zámek uˇz neexistuje, m˚ uˇze doj´ıt k n´ asleduj´ıc´ı chybˇe. Prvn´ı proces smaˇze zámek a znovu ho vytvoˇr´ı se sv´ ym PID. Dalˇs´ı proces udˇelá totéˇz, protoˇze operace pˇreˇcten´ı obsahu souboru a jeho n´ asledného smazán´ı nen´ı atomická. Ted’ si ale oba procesy mysl´ı, ˇze z´ıskaly z´ amek! • probl´ em: funkce lock() obsahuje aktivn´ı ˇcekán´ı na uvolnˇen´ı zámku. Lze ˇreˇsit napˇr. tak, ˇze proces, kter´ y z´ıská zámek, otevˇre pro zápis pojmenovanou ˇ rouru. Cekaj´ ıc´ı procesy se usp´ı t´ım, ˇze zkus´ı ˇc´ıst z roury. Souˇcást´ı unlock() bude i zavˇren´ı roury a t´ım uvolnˇen´ı ˇcekaj´ıc´ıch proces˚ u. Upozorˇ nuji na to, ˇ ze zkouˇ skov´ e pˇ r´ıklady pro zad´ an´ı obsahuj´ıc´ı jakoukoli synchronizaci nejsou akceptov´ any jako spr´ avn´ e, pokud je jakkoli pouˇ zito aktivn´ı ˇ cek´ an´ı, vˇ cetnˇ e uk´ azan´ eho ˇ reˇ sen´ı typu sleep(1) volan´ eho ve smyˇ cce. 166

• lock soubory se v praxi vˇetˇsinou pouˇz´ıvaj´ı pouze pro situace, kdy se napˇr´ıklad hl´ıd´ a n´ asobné spuˇstˇen´ı téˇze aplikace. Ze zkuˇ senosti radˇ eji opˇ et upozorˇ nuji, ˇ ze pokud je bude student na zkouˇ sce pouˇ z´ıvat napˇ r´ıklad pro synchronizaci vl´ aken, neuspˇ eje.

Zamyk´ an´ı soubor˚ u: fcntl() int fcntl(int fildes, int cmd, ...); • k nastaven´ı z´ amk˚ u pro soubor fildes se pouˇz´ıvá cmd: – F GETLK . . . vezme popis zámku z tˇret´ıho argumentu a nahrad´ı ho popisem existuj´ıc´ıho zámku, kter´ y s n´ım koliduje – F SETLK . . . nastav´ı nebo zruˇs´ı zámek popsan´ y tˇret´ım argumentem, pokud nelze zámek nastavit, ihned vrac´ı −1 – F SETLKW . . . jako F SETLK, ale usp´ı proces, dokud nen´ı moˇzné nastavit z´ amek (W znamená “wait”) • tˇret´ı argument obsahuje popis zámku a je typu ukazatel na struct flock

• zamyk´ an´ı soubor˚ u sd´ılen´ ych pˇres NFS zajiˇst’uje démon lockd. • z´ amky jsou obecnˇe dvou typ˚ u: advisory locks – pro spr´ avnou funkci mus´ı vˇsechny procesy pracuj´ıc´ı se z´ amˇcen´ ymi soubory kontrolovat zámky pˇred ˇcten´ım nebo zápisem souboru; jsou v´ıce pouˇz´ıvané mandatory locks – jestliˇze je na souboru zámek, budou ˇctec´ı a zápisové operace se souborem automaticky zablokovány, tj. zámek se uplatn´ı i v procesech, které ho explicitnˇe nekontroluj´ı – nedoporuˇcuj´ı se, ne vˇzdy funguj´ı (napˇr. lockd implementuje pouze advisory locking) – pro urˇcit´ y soubor se zapne nastaven´ım bitu SGID a zruˇsen´ım práva spuˇstˇen´ı pro skupinu (tj. nastaven´ı, které jinak nemá velk´ y smysl - m´ıt set GID executable bit na souboru, kter´ y nen´ı spustiteln´ y). Funguje to tak, ˇze jeden proces si vezme zámek na daném souboru (napˇr. pomoc´ı fcntl). Dalˇs´ı procesy pak nemus´ı explicitnˇe zamykat, protoˇze kaˇzdou operaci open/read/write s dan´ ym souborem kontroluje kernel proti zámk˚ um na souboru a vynut´ı ˇcekán´ı aˇz do chv´ıle kdy je z´ amek explicitnˇe prvn´ı procesem uvolnˇen.

167

Systém, kter´ y mandatory locking implementuje, je napˇr´ıklad Solaris nebo Linux, FreeBSD tuto vlastnost naopak nepodporuje. Manu´ alov´ a str´ anka fcntl(2) na Linuxu (2013) nedporuˇcuje mandatory locking pouˇz´ıvat, protoˇze Linuxová implementace obsahuje chyby které vedou k soubˇehu a mandatory zamykán´ı nedokáˇze tedy zajistit konzistenci. • Je d˚ uleˇzité si uvˇedomit, ˇze po skonˇcen´ı procesu se vˇsechny zámky, které drˇzel uvoln´ı.

Zamyk´ an´ı soubor˚ u: struct flock • l type . . . typ z´ amku – F RDLCK . . . sd´ılen´ y zámek (pro ˇcten´ı), v´ıce proces˚ u – F WRLCK . . . exkluzivn´ı zámek (pro zápis), jeden proces – F UNLCK . . . odemˇcen´ı • l whence . . . jako u lseek(), tj. SEEK SET, SEEK CUR, SEEK END atek zamykaného u ´seku vzhledem k l whence • l start . . . zaˇc´ • l len . . . délka u ´seku v bajtech, 0 znamená do konce souboru • l pid . . . PID procesu drˇz´ıc´ıho zámek, pouˇz´ıvá se jen pro F GETLK pˇri n´ avratu

• soubory se daj´ı zamykat po ˇcástech a dá se zjistit, kter´ y proces drˇz´ı zámek. Pˇri ukonˇcen´ı procesu se automaticky uvoln´ı vˇsechny jeho zámky. • pokud pˇri pouˇzit´ı F GETLK nen´ı pˇr´ısluˇsná ˇcást souboru zamˇcená, je struktura flock vr´ acena bez zmˇeny kromˇe prvn´ı poloˇzky, která je nastavena na F UNLCK. • pˇr´ıklad: file-locking/fcntl-locking.c • pˇr´ıklad na fcntl (je to pomoc´ı fcntl ,,opravená” verze dˇr´ıvejˇs´ıho pˇr´ıkladu race/race.c ze strany 167): race/fcntl-fixed-race.c . • zamyk´ an´ı pˇres fcntl i lockf má jednu d˚ uleˇzitou vlastnost, kterou v´ ystiˇznˇe popisuje napˇr´ıklad manu´ alová stránka pro fcntl v systému FreeBSD: This interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (“POSIX.1”) that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed 168

by that process. This semantic means that applications must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwnam(3) to retrieve a record, the lock will be lost because getpwnam(3) opens, reads, and closes the password database. • Funkce lockf (souˇc´ ast´ı SUSv3) je jednoduˇsˇs´ı variantou fcntl, specifikuje se pouze jak zamˇc´ıt a kolik bajt˚ u od souˇcasné pozice v souboru. Velmi ˇcasto je implementov´ ana jako wrapper kolem fcntl. • Pˇr´ıklad file-locking/lockf.c demonstruje jak funguje mandatory locking a ukazuje pouˇzit´ı funkce lockf.

Deadlock (aka uv´ aznut´ı) • m´ ame dva sd´ılené zdroje res1 a res2 chránˇené zámky lck1 a lck2. Procesy p1 a p2 chtˇej´ı kaˇzd´ y v´ yluˇcn´ y pˇr´ıstup k obˇema zdroj˚ um. p1 lock(lck1); /* OK */

p2

ˇ a na p2 */ lock(lck2); /* Cek´ use(res1, res2); unlock(lck2); unlock(lck1);

lock(lck2); /* OK */

ˇ a na p1 */ lock(lck1); /* Cek´ Deadlock use(res1, res2); unlock(lck2); unlock(lck1);

• pozor na poˇ rad´ı zamyk´ an´ı!

• obecnˇe deadlock vznikne, jestliˇze proces ˇceká na událost, která nem˚ uˇze nastat. Zde napˇr. na sebe dva procesy ˇcekaj´ı navzájem, aˇz ten druh´ y uvoln´ı z´ amek, ale k tomu nikdy nedojde. Dalˇs´ı moˇznost´ı je deadlock jednoho procesu, kter´ y ˇcte z roury a pˇredt´ım zapomnˇel uzavˇr´ıt zápisov´ y konec roury. Jestliˇze rouru nem´ a uˇz nikdo dalˇs´ı otevˇrenou, pokus o ˇcten´ı ze zablokuje, protoˇze nejsou zavˇreny vˇsechny kopie zápisového deskriptoru a tedy nenastane konec souboru na rouˇre, ale ˇctouc´ı proces sv˚ uj zápisov´ y deskriptor nem˚ uˇze zavˇr´ıt, protoˇze ˇcek´ a ve volán´ı read: int main(void) { int c, fd; mkfifo("test", 0666); 169

fd = open("test", O_RDWR); read(fd, &c, sizeof(c)); /* never reached */ return (0); } $ ./a.out ^C • fcntl() prov´ ad´ı kontrolu a pˇri v´ yskytu deadlocku vrát´ı chybu EDEADLK. • je vhodné se deadlocku snaˇzit vyvarovat správn´ ym naprogramován´ım a nespoléhat se na kontrolu systému.

System V IPC • IPC je zkratka pro Inter-Process Communication • komunikace mezi procesy v r´ amci jednoho syst´ emu, tj. nezahrnuje s´ıt’ovou komunikaci • semafory . . . pouˇzit´ı pro synchronizaci proces˚ u • sd´ılen´ a pamˇ et’ . . . pˇredáván´ı dat mezi procesy, pˇrináˇs´ı podobné problémy jako sd´ılen´ı soubor˚ u, k ˇreˇsen´ı lze pouˇz´ıt semafory • fronty zpr´ av . . . spojuj´ı komunikaci (zpráva nese data) se synchronizac´ı (ˇcek´ an´ı procesu na pˇr´ıchod zprávy) • prostˇredky IPC maj´ı podobnˇe jako soubory definovaná pˇ r´ıstupov´ a pr´ ava (pro ˇcten´ı a zápis) pro vlastn´ıka, skupinu a ostatn´ı.

• uvˇedomte si, ˇze tyto prostˇredky se vztahuj´ı ke konkrétn´ımu systému, System V, kde se objevily jako prvn´ı. Dalˇs´ı systémy je pak pˇrevzaly. Ze tˇ r´ı zde uveden´ ych synchronizaˇ cn´ıch prostˇ redk˚ u Systemu V se budeme zab´ yvat pouze semafory. Pro sd´ılenou pamˇ et’ je moˇ zn´ e pouˇ z´ıt jiˇ z probran´ e vol´ an´ı mmap, m´ısto zas´ıl´ an´ı zpr´ av je moˇ zn´ e pouˇ z´ıt sockety (budou v nˇ ekter´ e z pˇ r´ıˇ st´ıch pˇ redn´ aˇ sek). • prostˇredky IPC existuj´ı i poté, kdy skonˇc´ı proces, kter´ y je vytvoˇril. O jejich zruˇsen´ı je nutno explicitnˇe poˇzádat (ze shellu lze zjistit seznam IPC prostˇredk˚ u pˇr´ıkazem ipcs a smazat je pˇr´ıkazem ipcrm). Stav a obsah existuj´ıc´ıch prostˇredk˚ u IPC z˚ ustává v platnosti, i kdyˇz s nimi právˇe nepracuje ˇz´ adn´ y proces (napˇr. data ve sd´ılené pamˇeti z˚ ustávaj´ı, i kdyˇz ji nemá ˇzádn´ y proces pˇripojenou). 170

Semafory • zavedl je E. Dijkstra • semafor s je datov´ a struktura obsahuj´ıc´ı – celé nez´ aporné ˇc´ıslo i (volná kapacita) – frontu proces˚ u q, které ˇcekaj´ı na uvolnˇen´ı • operace nad semaforem: init(s, n) vypr´ azdnit s.q; s.i = n P(s) if(s.i > 0) s.i-- else uspat volaj´ ıc´ ı proces a zaˇ radit do s.q V(s) if(s.q pr´ azdn´ a) s.i++ else odstranit jeden proces z s.q a probudit ho

• P je z holandského ,,proberen te verlagen” – zkus dekrementovat, V pak ze slova ,,verhogen” – inkrementovat. • operace P(s) a V(s) lze zobecnit: hodnotu semaforu je moˇzné mˇenit o libovolnou hodnotu n . . . P(s, n), V(s, n). • Allen B. Downey: The Little Book of Semaphores, Second Edition, on-line na http://greenteapress.com/semaphores/ • bin´ arn´ı semafor m´ a pouze hodnotu 0 nebo 1

171

Vz´ ajemn´ e vylouˇ cen´ı pomoc´ı semafor˚ u • jeden proces inicializuje semafor sem s; init(s, 1); • kritick´ a sekce se dopln´ı o operace nad semaforem ... P(s); kritick´ a sekce; V(s); ...

• inicializace semaforu na hodnotu n dovol´ı vstoupit do kritické sekce n proces˚ um. Zde semafor funguje jako zámek, vˇzdy ho odemyká (zvyˇsuje hodnotu) stejn´ y proces, kter´ y ho zamknul (sn´ıˇzil hodnotu). • obecnˇe ale m˚ uˇze semafor zvednout jin´ y proces, neˇz kter´ y ho sn´ıˇzil; jinak by to ani nemˇelo velk´ y smysl. Je zde rozd´ıl oproti zámk˚ um, viz strana 233.

172

API pro semafory int semget(key t key, int nsems, int semflg ); • vr´ at´ı identifik´ ator pole obsahuj´ıc´ıho nsems semafor˚ u asociovan´ y s kl´ıˇcem key (kl´ıˇc IPC PRIVATE . . . privátn´ı semafory, pˇri kaˇzdém pouˇzit´ı vr´ at´ı jin´ y identifikátor). semflg je OR-kombinace pˇr´ıstupov´ ych práv a konstant IPC CREAT (vytvoˇrit, pokud neexistuje), IPC EXCL (chyba, pokud existuje). int semctl(int semid, int semnum, int cmd, ...); • ˇr´ıdic´ı funkce, voliteln´ y ˇctvrt´ y parametr arg je typu union semun. int semop(int semid, struct sembuf *sops, size t nsops ); • zobecnˇené operace P a V.

• jak z´ıskat kl´ıˇc pro semget je vysvˇetleno na strane 183. • nejvˇetˇs´ı zaj´ımavost na System V implementaci semafor˚ u je skuteˇcnost, ˇze dan´ y syscall neoperuje nad jedn´ım semaforem, ale nad polem semafor˚ u, a to atomicky. Vˇetˇsinou vˇsak budete potˇrebovat pouze jeden semafor, tj. pole o jednom prvku. Pro takové pouˇzit´ı jsou System V semafory zbyteˇcnˇe sloˇzité. • pˇr´ıstupov´ a pr´ ava jsou jen pro ˇcten´ı a zápis; bit execute zde nemá smysl. • podobné schéma API funkc´ı (funkce na vytvoˇren´ı, ˇr´ızen´ı a operace) dodrˇzuj´ı i ostatn´ı System V IPC mechanismy. • jakmile je jednou pole semafor˚ u jedn´ım procesem vytvoˇreno, mohou i ostatn´ı procesy pouˇz´ıt semctl() a semop(), aniˇz by pˇredt´ım volaly semget(). To plat´ı i pro semafory vytvoˇrené s kl´ıˇcem IPC PRIVATE, pro které nelze volat semget(), protoˇze by se t´ım vytvoˇrilo nové pole semafor˚ u. Je to tak proto, aby i priv´ atn´ı semafory mohly b´ yt dˇedˇené v rámci fork.

173

API pro semafory: semctl() • semnum . . . ˇc´ıslo semaforu v poli • moˇzné hodnoty cmd: – GETVAL . . . vr´ at´ı hodnotu semaforu – SETVAL . . . nastav´ı semafor na hodnotu arg.val – GETPID . . . PID procesu, kter´ y provedl posledn´ı operaci – GETNCNT . . . poˇcet proces˚ u ˇcekaj´ıc´ıch na vˇetˇs´ı hodnotu – GETZCNT . . . poˇcet proces˚ u ˇcekaj´ıc´ıch na nulu – GETALL . . . uloˇz´ı hodnoty vˇsech semafor˚ u do pole arg.array – SETALL . . . nastav´ı vˇsechny semafory podle arg.array – IPC STAT . . . do arg.buf dá poˇcet semafor˚ u, pˇr´ıstupová pr´ ava a ˇcasy posledn´ıch semctl() a semop() – IPC SET . . . nastav´ı pˇr´ıstupová práva – IPC RMID . . . zruˇs´ı pole semafor˚ u

• vol´ an´ı semctl(semid, semnum, SETVAL, arg) odpov´ıdá obecné semaforové inicializaˇcn´ı operaci init(s, n).

174

API pro semafory: semop() • operace se prov´ ad´ı atomicky (tj. bud’ se povede pro vˇsechny semafory, nebo pro ˇz´ adn´ y) na nsops semaforech podle pole sops struktur struct sembuf, která obsahuje: – sem num . . . ˇc´ıslo semaforu – sem op . . . operace ∗ P(sem num, abs(sem op)) pro sem op < 0 ∗ V(sem num, sem op) pro sem op > 0 ∗ ˇcek´ an´ı na nulovou hodnotu semaforu pro sem op == 0 – sem flg . . . OR-kombinace ∗ IPC NOWAIT . . . kdyˇz nelze operaci hned provést, neˇceká a vr´ at´ı chybu ∗ SEM UNDO . . . pˇri ukonˇcen´ı procesu vrátit operace se semaforem

• atomiˇcnost pˇres mnoˇzinu semafor˚ u zajist´ı, ˇze nedojde k deadlocku v následuj´ıc´ı situaci: dva procesy A a B budou pouˇz´ıvat dva semafory k ˇr´ızen´ı pˇr´ıstupu (zamyk´ an´ı) ke dvˇema systémov´ ym zdroj˚ um. Proces A je bude zamykat v poˇrad´ı (0, 1) a proces B v poˇrad´ı (1, 0). Ve chv´ıli, kdy proces A zamkne semafor 0 a B zamkne 1, dojde k deadlocku, protoˇze ani jeden proces nem˚ uˇze pokraˇcovat (potˇreboval by zamknout druh´ y semafor). Pˇri pouˇzit´ı atomické operace zamˇcen´ı obou semafor˚ u najednou bude u ´spˇeˇsn´ y vˇzdy právˇe jeden proces, kter´ y z´ısk´ a oba semafory, druh´ y bude ˇcekat. • SEM UNDO zajist´ı, ˇze pˇri ukonˇcen´ı procesu dojde k odemˇcen´ı semafor˚ u (pouˇzit´ ych jako z´ amky), které tento proces mˇel zamˇcené.

175

Vytv´ aˇ ren´ı prostˇ redk˚ u IPC • jeden proces prostˇredek vytvoˇr´ı, ostatn´ı se k nˇemu pˇripoj´ı. • po skonˇcen´ı pouˇz´ıv´ an´ı je tˇreba prostˇredek IPC zruˇsit. • funkce semget(), shmget() a msgget() maj´ı jako prvn´ı parametr kl´ıˇc identifikuj´ıc´ı prostˇredek IPC. Skupina proces˚ u, kter´ a chce komunikovat, se mus´ı domluvit na spoleˇcném kl´ıˇci. R˚ uzné skupiny komunikuj´ıc´ıch proces˚ u by mˇely m´ıt r˚ uzné kl´ıˇce. key t ftok(const char *path, int id ); • vr´ at´ı kl´ıˇc odvozen´ y ze zadaného jména souboru path a ˇc´ısla id. Pro stejné id a libovolnou cestu odkazuj´ıc´ı na stejn´ y soubor vr´ at´ı stejn´ y kl´ıˇc. Pro r˚ uzná id nebo r˚ uzné soubory na stejném svazku vr´ at´ı r˚ uzné kl´ıˇce.

pozn´ amky k ftok(): • z id se pouˇzije jen nejniˇzˇs´ıch 8 bit˚ u. • nen´ı specifikov´ ano, zda bude stejn´ y kl´ıˇc vrácen i po smazán´ı a znovuvytvoˇren´ı souboru. Vˇetˇsinou ne, protoˇze v kl´ıˇci se ˇcasto odráˇz´ı ˇc´ıslo indexového uzlu. • r˚ uzné kl´ıˇce pro r˚ uzné soubory nejsou vˇzdy zaruˇcené. Napˇr. na Linuxu se kl´ıˇc z´ısk´ a kombinac´ı 16 bit˚ u ˇc´ısla i-uzlu, 8 bit˚ u id a 8 bit˚ u vedlejˇs´ıho ˇc´ısla zaˇr´ızen´ı. Stejn´ y kl´ıˇc pro r˚ uzné soubory je vrácen, pokud se ˇc´ısla i-uzl˚ u shoduj´ı na spodn´ıch 16 bitech. • pokud tedy nepˇr´ıbuzné procesy chtˇej´ı pouˇz´ıvat stejn´ y semafor, mus´ı b´ yt jm´ eho souboru pro kl´ıˇ c domluveno pˇ redem. • pˇr´ıklad na semafory (je to pomoc´ı semafor˚ u ,,opravená” verze dˇr´ıvejˇs´ıho pˇr´ıkladu race/race.c ze strany 167): race/sem-fixed-race.c .

176

Dalˇ s´ı prostˇ redky IPC • POSIX a SUSv3 definuj´ı jeˇstˇe dalˇs´ı prostˇredky komunikace mezi procesy: – sign´ aly . . . pro uˇzivatelské u ´ˇcely lze vyuˇz´ıt signály SIGUSR1 a SIGUSR2 – POSIXov´ a sd´ılen´ a pamˇ et’ pˇr´ıstupná pomoc´ı shm open() a mmap() – POSIXov´ e semafory . . . sem open(), sem post(), sem wait(), . . . – POSIXov´ e fronty zpr´ av . . . mq open(), mq send(), mq receive(), . . . • Z BSD poch´ az´ı sokety (sockets) umoˇzn ˇuj´ıc´ı komunikaci v domén´ ach AF UNIX (komunikace v rámci jednoho poˇc´ıtaˇce) a AF INET (komunikace na jednom poˇc´ıtaˇci nebo po s´ıti).

• POSIXové IPC pouˇz´ıv´ a pro pojmenován´ı jednotliv´ ych IPC objekt˚ u ˇretˇezce m´ısto numerick´ ych identifik´ ator˚ u, proto do znaˇcné m´ıry odpadaj´ı problémy s identifikac´ı zn´ amé ze System V IPC (kde se ˇreˇs´ı napˇr. funkc´ı ftok()). • POSIXov´ a rozhran´ı zde uvedená jsou souˇcást´ı rozˇs´ıˇren´ı 1003.1b (aka POSIX.4), viz strana 6. • sokety se z BSD rozˇs´ıˇrily i do ostatn´ıch UNIXov´ ych systém˚ u a dostaly se i do normy SUSv2. • existuj´ı dalˇs´ı API specifické pro konkrétn´ı systém, napˇr. Solaris doors.

177


S´ıt’ov´ a komunikace UUCP (UNIX-to-UNIX Copy Program) – prvn´ı aplikace pro komunikaci UNIXov´ ych systém˚ u propojen´ ych pˇr´ımo nebo pˇres modemy, souˇc´ ast Version 7 UNIX (1978) sokety (sockets) – zavedeny ve 4.1aBSD (1982); soket je jeden konec obousmˇerného komunikaˇcn´ıho kanálu vytvoˇreného mezi dvˇema procesy bud’ lokálnˇe na jednom poˇc´ıtaˇci, nebo s vyuˇzit´ım s´ıt’ového spojen´ı TLI (Transport Layer Interface) – SVR3 (1987); knihovna zajiˇst’uj´ıc´ı s´ıt’ovou komunikaci na u ´rovni 4. vrstvy referenˇcn´ıho modelu ISO OSI RPC (Remote Procedure Call) – SunOS (1984); protokol pro pˇr´ıstup ke sluˇzb´ am na vzdáleném stroji, data pˇrenáˇsena ve tvaru XDR (External Data Representation)

178

• ISO (International Standards Organization) OSI (Open Systems Interconnect) – vrstvy (layers): 1. 2. 3. 4. 5. 6. 7.

fyzick´ a (physical) linkov´ a (data link) s´ıt’ov´ a (network) transportn´ı (transport) relaˇcn´ı (session) prezentaˇcn´ı (presentation) aplikaˇcn´ı (application)

• UUCP je tvoˇreno aplikaˇcn´ımi programy, nevyˇzaduje ˇzádnou podporu v jádru. Implementace soket˚ u a TLI jsou souˇcást´ı jádra. TLI je ve verzi SVR4 implementov´ ano s vyuˇzit´ım mechanismu STREAMS. RPC existuje jako knihovna linkovan´ a k aplikac´ım, kter´ a vyuˇz´ıvá sokety (funguje nad protokoly TCP a UDP). RPC bylo vyvinuto jako komunikaˇcn´ı protokol pro NFS (Networked File System). • existuje v´ıce (vz´ ajemnˇe nekompatibiln´ıch) implementac´ı RPC • komunikaˇcn´ı kan´ al je specifikován adresami dvou soket˚ u. • sokety pro komunikaci pouze v rámci jednoho poˇc´ıtaˇce jsou v doménˇe AF UNIX a jejich jména jsou jména speciáln´ıch soubor˚ u, které reprezentuj´ı sokety v systému soubor˚ u. • sokety AF UNIX jsou nˇeco jiného neˇz lokáln´ı TCP/IP komunikace pˇres loopback rozhran´ı localhost (127.0.0.1). V´ıce o AF UNIX na stranˇe 192.

TCP/IP • protokoly – IP (Internet Protocol) – pˇr´ıstupn´ y jen pro uˇzivatele root – TCP (Transmission Control Protocol) – streamov´ y, spojovan´ y, spolehliv´ y – UDP (User Datagram Protocol) – datagramov´ y, nespojovan´ y, nespolehliv´ y • IP adresa – 4 bajty (IPv4) / 16 bajt˚ u (IPv6), definuje s´ıt’ové rozhran´ı, nikoliv poˇc´ıtaˇc • port – 2 bajty, rozliˇsen´ı v rámci 1 IP adresy, porty s ˇc´ıslem menˇs´ım neˇz 1024 jsou rezervované (jejich pouˇzit´ı vyˇzaduje pr´ ava uˇzivatele root) • DNS (Domain Name System) – pˇrevod mezi symbolick´ ymi jmény a numerick´ ymi IP adresami

179

• pokud nev´ıte, o ˇcem je ˇreˇc, doporuˇcuji Peterkovy pˇrednáˇsky; jsou volnˇe ke staˇzen´ı na webu. Jsou to nejlepˇs´ı materiály, které jsem k dané problematice vidˇel. • UNIX pouˇz´ıv´ a pro s´ıt’ovou komunikaci nejˇcastˇeji rodinu protokol˚ u TCP/IP. Pro u ´ˇcely programov´ an´ı aplikac´ı nás budou zaj´ımat pˇredevˇs´ım protokoly TCP (spojovan´ a spolehliv´ a komunikace) a UDP (nespojovaná nespolehlivá komunikace). V obou protokolech je jeden konec komunikaˇcn´ıho kanálu (odpov´ıd´ a soketu) identifikov´ an IP adresou s´ıt’ového rozhran´ı a ˇc´ıslem portu (pomoc´ı port˚ u se rozliˇsuj´ı s´ıt’ové sluˇzby bˇeˇz´ıc´ı na jednom poˇc´ıtaˇci). TCP spojen´ı je pak jednoznaˇcnˇe definov´ ano jedn´ım párem soket˚ u. • IP – protokol 3. vrstvy, zajiˇst’uje pˇrenos paket˚ u (datagram˚ u) mezi rozhran´ımi identifikovan´ ymi IP adresou; je nespolehliv´ y (nezaruˇcuje doruˇcen´ı dat). Je definov´ an v RFC 791. Ned´ılnou souˇcást´ı IP je Internet Control Message Protocol (ICMP), RFC 792. • UDP – jednoduch´ a nadstavba nad IP, pˇridává ˇc´ısla port˚ u, z˚ ustává nespolehliv´ y a datagramovˇe orientovan´ y. RFC 768. • TCP – vytv´ aˇr´ı obousmˇerné spojen´ı mezi dvˇema body (IP+port), poskytuje tok dat (stream) bez rozdˇelen´ı na zprávy, zajiˇst’uje ˇr´ızen´ı toku dat a spolehlivé doruˇcov´ an´ı. Pro vytvoˇren´ı spojen´ı je tˇreba provést tzv. handshake. RFC 793. • DNS – hierarchicky organizovaná databáze, jej´ı struktura nemus´ı m´ıt nic spoleˇcného se strukturou IP adres

Spojovan´ e sluˇ zby (TCP), sekvenˇ cn´ı obsluha server

s´ıt’

fd = socket()

klient

fd = socket()

bind(fd) listen(fd) fd2 = accept(fd)

connect(fd)

read(fd2); write(fd2)

write(fd);read(fd)

close(fd2)

close(fd)

180

• uvˇedomte si, ˇze se pouˇz´ıvaj´ı bˇeˇzná read a write volán´ı. • server vytvoˇr´ı jedno spojen´ı, teprve po jeho ukonˇcen´ı akceptuje dalˇs´ıho klienta. • systémov´ a vol´ an´ı: – socket – vytvoˇr´ı soket, vrát´ı jeho deskriptor – bind – definuje adresu soketu (IP adresu a ˇc´ıslo portu), mus´ı to b´ yt bud’ adresa jednoho ze s´ıt’ov´ ych rozhran´ı poˇc´ıtaˇce, na kterém je vytvoˇren soket; pak bude soket pˇrij´ımat ˇzádosti klient˚ u pouze pˇres toto rozhran´ı, nebo je to speciáln´ı hodnota ,,libovolná adresa”; pak soket pˇrij´ım´ a poˇzadavky prostˇrednictv´ım vˇsech s´ıt’ov´ ych rozhran´ı (tzv. wildcard socket). – listen – ozn´ am´ı j´ adru, ˇze soket bude pˇrij´ımat poˇzadavky klient˚ u – accept – usp´ı proces, dokud nebude k dispozici nˇejaká ˇzádost klienta o spojen´ı, vytvoˇr´ı spojen´ı a vrát´ı nov´ y deskriptor, pˇres kter´ y bude prob´ıhat dalˇs´ı komunikace s klientem, p˚ uvodn´ı deskriptor lze pouˇz´ıt k novému vol´ an´ı accept pro obslouˇzen´ı dalˇs´ıho klienta – close – ukonˇc´ı komunikaci – connect – ˇz´ adost klienta o navázán´ı spojen´ı, IP adresa a ˇc´ıslo portu serveru se zad´ avaj´ı jako parametry, komunikace prob´ıhá pˇres deskriptor fd (na rozd´ıl od accept nevytváˇr´ı nov´ y deskriptor) • klient nemus´ı volat bind, v takovém pˇr´ıpadˇe mu jádro pˇridˇel´ı nˇekter´ y voln´ y port. Existuj´ı sluˇzby (napˇr. rsh), které vyˇzaduj´ı, aby se klient spojoval z privilegovaného portu (porty 0-1023). Takov´ y klient pak mus´ı provést bind (a nav´ıc bˇeˇzet s dostateˇcn´ ymi právy alespoˇ n do okamˇziku proveden´ı bind; dostateˇcn´ a pr´ ava mohou znamenat uˇzivatele root nebo speciáln´ı privilegium/capability).

181

Spojovan´ e sluˇ zby (TCP), paraleln´ı obsluha server

s´ıt’

fd = socket() bind(fd) listen(fd) fd2 = accept(fd) fork()

klient

fd = socket()

connect(fd)

close(fd2) syn while(waitpid( read(fd2) -1, stat, write(fd2) WNOHANG)>0) ; exit(0)

write(fd);read(fd) close(fd)

• server akceptuje spojen´ı od klienta a na vlastn´ı komunikaci vytvoˇr´ı nov´ y proces, kter´ y po uzavˇren´ı spojen´ı s klientem skonˇc´ı. Rodiˇcovsk´ y proces m˚ uˇze mezit´ım akceptovat dalˇs´ı klienty a spouˇstˇet pro nˇe obsluˇzné procesy. Souˇcasnˇe je tedy obsluhov´ ano v´ıce klient˚ u. • po proveden´ı fork, ale pˇred zahájen´ım obsluhy spojen´ı, m˚ uˇze synovsk´ y proces provést exec – takto funguje napˇr. inetd (strana 214). • vol´ an´ı waitpid v cyklu odstraˇ nuje ze systému zombie. Jinou moˇznost´ı je vyuˇzit´ı sign´ alu SIGCHLD, jehoˇz explicitn´ı ignorován´ı zabrán´ı vzniku ˇziv´ ych mrtv´ ych, popˇr. lze instalovat handler, v nˇemˇz se volá wait.

182

Spojovan´ e sluˇ zby, paraleln´ı accept() server

s´ıt’

fd = socket() bind(fd) listen(fd) fork()

...

klient

fd = socket()

fd2=accept(fd) read(fd2) write(fd2) close(fd2)

connect(fd) write(fd);read(fd) close(fd)

• po bind a listen se vytvoˇr´ı nˇekolik synovsk´ ych proces˚ u a kaˇzd´ y v cyklu volá accept a obsluhuje klienty. Jádro, pro uˇzivatele nedeterministicky, vybere pro kaˇzd´ y poˇzadavek jeden proces, v nˇemˇz accept naváˇze spojen´ı. Hlavn´ı proces ˇz´ adné poˇzadavky nevyˇrizuje, ale ˇceká v nˇekterém z volán´ı typu wait a vytv´ aˇr´ı procesy, kdyˇz je potˇreba. • jednotlivé procesy serveru mezi sebou mohou komunikovat, aby v pˇr´ıpadˇe, ˇze souˇcasn´ ych poˇzadavk˚ u je v´ıce neˇz serverov´ ych proces˚ u, se tato skuteˇcnost zjistila a hlavn´ı server mohl dynamicky vytvoˇrit dalˇs´ı serverov´ y proces. • takto funguje napˇr. webov´ y server Apache. Je moˇzné definovat, kolik poˇzadavk˚ u m´ a potomek zpracovat, neˇz sám skonˇc´ı. T´ımto zp˚ usobem se v´ yraznˇe omez´ı n´ asledky pˇr´ıpadn´ ych problém˚ u, napˇr´ıklad neuvolˇ nován´ı pamˇeti, tzv. memory leaks. • vˇ sechny tˇ ri uveden´ e zp˚ usoby ˇ cinnosti serveru funguj´ı se stejn´ ym klientem – ˇcinnost klienta nezávis´ı na variantˇe serveru.

183

Datagramov´ e sluˇ zby (UDP) server

s´ıt’

klient

fd = socket()

fd = socket() bind(fd) recvfrom(fd) sendto(fd)

sendto(fd) recvfrom(fd)

close(fd)

• z pohledu volan´ ych s´ıt’ov´ ych funkc´ı je funkce serveru a klienta shodná. Klient je zde ten, kdo poˇsle prvn´ı datagram. • stejnˇe jako v pˇr´ıpadˇe TCP, klient nemus´ı dˇelat bind, jestliˇze mu nezáleˇz´ı na tom, jaké ˇc´ıslo portu bude pouˇz´ıvat. Server zjist´ı port klienta z obsahu adresn´ı ˇc´ asti datagramu. • v´ yhodou nespojované sluˇzby je menˇs´ı reˇzie a to, ˇze pˇres jeden soket lze komunikovat s v´ıce procesy (pˇri spojované komunikaci je spojen´ı vˇzdy navázáno s jedn´ım procesem). • pro UDP je moˇzné volat connect. T´ım se nenaváˇze spojen´ı, ale soket se nastav´ı tak, ˇze m˚ uˇze nad´ ale komunikovat pouze s adresou a portem specifikovan´ ymi ve vol´ an´ı connect. M´ısto sendto a recvfrom se pak pouˇz´ıvaj´ı funkce send a recv.

184

Vytvoˇ ren´ı soketu: socket() int socket(int domain, int type, int protocol ); • vytvoˇr´ı soket a vr´ at´ı jeho deskriptor. • domain – ,,kde se bude komunikovat”: – AF UNIX . . . lok´ aln´ı komunikace, adresa je jméno souboru – AF INET, AF INET6 . . . s´ıt’ová komunikace, adresa je dvojice (IP adresa, port) • type: – SOCK STREAM . . . spojovaná spolehlivá sluˇzba, poskytuje obousmˇern´ y sekvenˇcn´ı proud dat – SOCK DGRAM . . . nespojovaná nespolehlivá sluˇzba, pˇrenos datagram˚ u • protocol: 0 (default pro dan´ y type) nebo platné ˇc´ıslo protokolu (napˇr. 6 = TCP, 17 = UDP)

• funkce je deklarov´ ana v <sys/socket.h>, stejnˇe jako funkce z dalˇs´ıch slajd˚ u – bind, listen, a accept, a pouˇzité konstanty. • sokety jsou pˇ r´ıstupn´ e pˇ res deskriptory soubor˚ u. Po navázán´ı spojen´ı je (spojovan´ a) komunikace pˇres soket podobná komunikaci pomoc´ı roury s t´ım rozd´ılem, ˇze sokety jsou vˇzdy obousmˇ ern´ e, coˇz nemus´ı platit u rour, viz strana 143. • ˇcasto uvid´ıte konstanty zaˇc´ınaj´ıc´ı PF_ (jako protocol family, napˇr. PF INET, PF_UNIX, nebo PF INET6) a pouˇz´ıvané ve volán´ı socket. Konstanty AF_ (address family) jsou pak pouˇz´ıvané pouze pˇri zadáván´ı adres soket˚ u. I kdyˇz to snad d´ av´ a vˇetˇs´ı smysl, norma specifikuje pouze AF konstanty pro pouˇzit´ı pro vol´ an´ı socket i pro zad´ aván´ı adres. Hodnoty odpov´ıdaj´ıc´ıch konstant PF jsou pak stejné, tj. definované pomoc´ı AF konstant. Doporuˇcuji pouˇz´ıvat jen AF. • existuj´ı dalˇs´ı typy soket˚ u pro pln´ y pˇr´ıstup k danému protokolu (SOCK RAW), nebo k informac´ım z routovac´ı tabulky. Pro pouˇzit´ı SOCK RAW typicky potˇrebujete dodateˇcn´ a privilegia – proto napˇr´ıklad pˇr´ıkaz ping, kter´ y vyplˇ nuje ICMP hlaviˇcky odes´ılan´ ych paket˚ u, b´ yvá nastaven jako SUID: $ ls -l /usr/sbin/ping -r-sr-xr-x 1 root bin

55680 Nov 14 19:01 /usr/sbin/ping

185

Pojmenov´ an´ı soketu: bind() int bind(int socket, const struct sockaddr *address, socklen t address len ); • pˇriˇrad´ı soketu zadanému deskriptorem socket adresu • obecn´ a struct sockaddr, nepouˇz´ıvá se pro vlastn´ı zadáván´ı adres: – sa family t sa family . . . doména – char sa data [] . . . adresa • pro AF INET se pouˇz´ıv´ a struct sockaddr in: – sa family t sin family . . . doména (AF INET) – in port t sin port . . . ˇc´ıslo portu (16 bit˚ u) u) – struct in addr sin addr . . . IP adresa (32 bit˚ – unsigned char sin zero [8] . . . v´ yplˇ n (padding)

• vol´ an´ı bind pˇriˇrazuje soketu lok´ aln´ı adresu, tj. zdrojovou adresu odes´ılan´ ych dat a c´ılovou adresu pˇrij´ıman´ ych dat. Vzdálená adresa, tj. adresa druhého konce komunikaˇcn´ıho kan´ alu, se nastavuje pomoc´ı connect. • struktura sockaddr je obecn´ y typ, pouˇz´ıvan´ y kernelem. Pro konkrétn´ı nastaven´ı adres pak podle zvolené domény a typu lze pouˇz´ıt ,,konkrétnˇejˇs´ı” struktury k tomu definované (viz dalˇs´ı slajd), které je pak nutné pˇri pouˇzit´ı v bind pˇretypovat na struct sockaddr. V naprosté vˇetˇsinˇe pˇr´ıpad˚ u je ale pouˇzit´ı tˇechto struktur zbyteˇcné a nedoporuˇcené - program pak bude fungovat pouze pro jednu address family. Pˇri pouˇzit´ı obecn´ ych funkc´ı pro pˇrevod jmen na adresy se lze pouˇzit´ı tˇechto struktur u ´plnˇe vyhnout - viz funkce getaddrinfo na stranˇe 205. • Budete potˇrebovat i dalˇs´ı hlaviˇckové soubory. Pˇr´ıklad je na stranˇe 194. • pro domény AF INET a AF INET6 lze zadat ˇc´ıslo portu a speciáln´ı hodnotu IP adresy, kter´ a znamen´ a libovolnou adresu na daném stroji. Na takov´ y soket (wildcard soket) pak bude moˇzné pˇr´ıj´ımat poˇzadavky na kteroukoli IP adresu nastavenou na kterékoli s´ıt’ové kartˇe. Je moˇzné zadat i jednu konkrétn´ı adresu, k tomu se dostaneme. – pro AF INET je to hodnota INADDR ANY (4 nulové bajty odpov´ıdaj´ıc´ı adrese 0.0.0.0) – u AF INET6 je situace komplikovanˇejˇs´ı, bud’to lze pouˇz´ıt konstantn´ı promˇennou in6addr any nebo konstantu IN6ADDR ANY INIT, kterou ale lze

186

pouˇz´ıt pouze pro inicializaci promˇenné (typu struct in6 addr), nikoliv pro pˇriˇrazen´ı. Obˇe tyto hodnoty odpov´ıdaj´ı adrese :: (16 nulov´ ych bajt˚ u). • nelze spojit v´ıce soket˚ u s jednou dvojic´ı (adresa, port). • vol´ an´ı bind lze vynechat, j´ adro pak soketu (v pˇr´ıpadˇe TCP, UDP) pˇriˇrad´ı adresu a nˇekter´ y voln´ y port. Obvykle bind volá pouze server, protoˇze klienti oˇcek´ avaj´ı, ˇze bude poslouchat na pevném portu. Naopak klient pevn´ y port nepotˇrebuje, server se port klienta dozv´ı pˇri navázán´ı spojen´ı nebo z prvn´ıho pˇrijatého datagramu. • adresa i port mus´ı b´ yt do struktury uloˇ zeny vˇ zdy v s´ıt’ov´ em poˇ rad´ı bajt˚ u. Poˇrad´ı bajt˚ u bylo vysvˇetleno na stranˇe 19, dalˇs´ı informace pak jsou na stranˇe 204.

Struktura pro IPv4 adresy • kaˇzd´ a adresn´ı rodina má svoji strukturu a sv˚ uj hlaviˇckov´ y soubor • pouˇzitou strukturu pak ve volán´ı socket pˇretypujete na struct sockaddr #include struct sockaddr_in in; /* IPv4 */ bzero(&in, sizeof (in)); in.sin_family = AF_INET; in.sin_port = htons(2222); in.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(s, (struct sockaddr *)&in, sizeof (in)) == -1) ...

• Tento pˇr´ıklad slouˇz´ı ˇcistˇe pro demonstraci toho jak funguj´ı struktury uvnitˇr. Pokud to nen´ı nezbytnˇe nutné, nemˇel by kód kter´ y nap´ıˇsete tyto konstrukce obsahovat - pˇri pouˇzit´ı obecn´ ych funkc´ı pro pˇrevod jména na adresy vyplˇ nov´ an´ı struktur specifick´ ych pro danou address family odpadá. U vˇetˇsiny s´ıt’ov´ ych program˚ u se dnes pˇredpokládá, ˇze budou fungovat jak na IPv4, tak na IPv6. • u IPv4 je poloˇzka sin addr sama strukturou, typu in addr. Tato struktura mus´ı m´ıt alespoˇ n jednu poloˇzku, s addr, jej´ıˇz typ mus´ı b´ yt ekvivaletn´ı 4bajtovému integeru – pro ˇctyˇri bajty IPv4 adresy. To ˇr´ıká pˇr´ımo UNIX norma pro soubor netinet/in.h.

187

• sockaddr in6 je o nˇeco sloˇzitˇejˇs´ı. Je pˇr´ıstupn´ y z netinet/in.h (bud’to je v nˇem tato struktura pˇr´ımo definována nebo soubor inkluduje netinet6/in6.h s jej´ı definic´ı). yt port i adresa v s´ıt’ovém poˇrad´ı bajt˚ u, viz • u AF INET a AF INET6 mus´ı b´ strana 204. a jako 0, takˇze ˇcasto uvid´ıte jej´ı pouˇzit´ı bez htonl. • INADDR ANY je definovan´ Nen´ı to dobr´ y zvyk. Aˇz m´ısto tohoto makra vloˇz´ıte IP adresu definovanou integerem a zapomenete htonl pˇridat, je hned problém. Kdyˇz budete od zaˇc´ atku programovat jako sluˇsnˇe vychovan´ı lidé, toto se vám nem˚ uˇze stát. A kdyˇz budete ps´ at s´ıt’ové programy tak aby uˇz od zaˇcátku byly agnostické k address family, tak se tomuto problému vyhnete u ´plnˇe. • v doménˇe AF UNIX se pouˇz´ıvá adresová struktura struct sockaddr un, definovan´ a v <sys/un.h>: – sa family t sun family . . . doména – char sun path [] . . . jméno soketu – délka jména nen´ı ve standardu definována, závis´ı na implementaci. Obvyklé hodnoty jsou mezi 92 a 108.

ˇ an´ı na spojen´ı: listen() Cek´ int listen(int socket, int backlog ); • oznaˇc´ı soket zadan´ y desktriptorem socket jako akceptuj´ıc´ı spojen´ı a systém na soketu zaˇcne poslouchat. • maxim´ alnˇe backlog ˇz´ adost´ı o spojen´ı m˚ uˇze najednou ˇcekat ve frontˇe na obslouˇzen´ı (implementace m˚ uˇze hodnotu backlog ˇ adosti, které se zmˇenit, pokud nen´ı v podporovaném rozsahu). Z´ nevejdou do fronty, jsou odm´ıtnuty (tj. volán´ı connect skonˇc´ı s chybou). • soket ˇcek´ a na spojen´ı na adrese, která mu byla dˇr´ıve pˇriˇrazena vol´ an´ım bind.

• Wildcard sokety se pouˇz´ıv´ aj´ı pro server nejˇcastˇeji. Konkrétn´ı IP adresa serveru se zad´ av´ a tehdy, jestliˇze je potˇreba rozliˇsit, pˇres které s´ıt’ové rozhran´ı pˇriˇsel poˇzadavek na spojen´ı (pro kaˇzdé rozhran´ı máme jeden soket). Tuto moˇznost vyuˇz´ıvaly web servery, které podle IP adresy rozliˇsovaly virtuáln´ı

188

servery. Obvykle se na takovém serveru jednomu fyzickému rozhran´ı pˇriˇradilo nˇekolik IP adres (IP aliasing). To je ale jiˇz dávno minulost´ı – rozliˇsen´ı virtu´ aln´ıch server˚ u podle HTTP hlaviˇcky ,,Host:” uˇz nepotˇrebuje IP aliasy. Podobnˇe TLS protokol obsahuje rozˇs´ıˇren´ı ServerName. • To ˇze systém zaˇcne na portu poslouchat znamená, ˇze po pˇripojen´ı probˇehne TCP handshake a systém zaˇcne pˇrij´ımat data. Data se ukládaj´ı do bufferu s omezenou velikost´ı, a po dosaˇzen´ı jeho limitu je spojen´ı sice stále aktivn´ı, ale TCP window je nastaveno na 0 – systém dalˇs´ı data pˇrestal pˇrij´ımat. Velikost bufferu b´ yv´ a v ˇr´ adu des´ıtek kilobajt˚ u. Pˇr´ıklad: tcp/up-to-listen-only.c . • V pˇr´ıkladu je pouˇzito makro SOMAXCONN, vyˇzadované normou v souboru sys/socket.h. Specifikuje maximáln´ı povolenou délku fronty pro listen(). Co se d´ıv´ am na r˚ uzné verze systém˚ u co mám k dispozici, tak Linux, FreeBSD, Mac OS X i Solaris pouˇz´ıvaj´ı pro toto makro hodnotu 128.

Akceptov´ an´ı spojen´ı: accept() int accept(int socket, struct sockaddr *address, socklen t *address len ); • vytvoˇr´ı spojen´ı mezi lokáln´ım soketem socket (kter´ y dˇr´ıve zavolal listen) a vzd´ alen´ ym soketem, ˇzádaj´ıc´ım o spojen´ı pomoc´ı connect. Vr´ at´ı deskriptor (nov´ y soket), kter´ y lze pouˇz´ıvat pro komunikaci se vzdálen´ ym procesem. P˚ uvodn´ı soket m˚ uˇze hned pˇrij´ımat dalˇs´ı spojen´ı pomoc´ı accept. • v address vr´ at´ı adresu vzdáleného soketu. • address len je velikost struktury pro uloˇzen´ı adresy v bajtech, po n´ avratu obsahuje skuteˇcnou délku adresy.

• Vytvoˇren´ı druhého deskriptoru pro komunikaci umoˇzn ˇuje na tom p˚ uvodn´ım ihned znovu volat accept. • Novˇe vytvoˇren´ y soket m´ a stejné vlastnosti, jako má soket socket, tj. pokud je napˇr´ıklad neblokuj´ıc´ı, je i nov´ y soket neblokuj´ıc´ı. • Jestliˇze se v´ıce klient˚ u ze stejného poˇc´ıtaˇce najednou pˇripoj´ı k jednomu serveru (tj. na jednu serverovou IP adresu a jeden port), jsou jednotlivá spojen´ı rozliˇsena jen ˇc´ıslem portu na klientské stranˇe. Nezapomeˇ nte, ˇze TCP spojen´ı je jednoznaˇcnˇe definov´ ano dvˇema sokety, tj. ((addr1, port1), (addr2, port2)).

189

• address m˚ uˇze b´ yt zad´ ana jako NULL, ˇc´ımˇz oznamujeme, ˇze nás konkrétn´ı adresa naˇseho nového soketu nezaj´ımá. V tomto pˇr´ıpadˇe by i address len mˇelo b´ yt 0. • Pokud je program naps´ an správnˇe a je tedy nezávisl´ y na address family, mˇel by v druhém argumentu pˇredávat adresu struktury struct sockaddr storage (do které se vejde jak´ akoliv struktura specifická pro danou address family, tedy struct sockaddr in nebo struct sockaddr in6) a v tˇret´ım argumentu jej´ı délku. • Pˇr´ıklad: tcp/tcp-sink-server.c

Pr´ ace s IPv4 a IPv6 adresami • bin´ arn´ı reprezentace adresy se nám ˇspatnˇe ˇcte • a reprezentaci adresy ˇretˇezcem nelze pouˇz´ıt pˇri práci se sockaddr strukturami int inet pton(int af, const char *src, void *dst ); • pˇrevede ˇretˇezec na bin´ arn´ı adresu, tj. to co je moˇzné pouˇz´ıt v in addr nebo in6 addr poloˇzkách sockaddr struktur • vrac´ı 1 (OK), 0 (chybnˇe zadaná adresa) nebo -1 (a nastav´ı errno) cont char *inet ntop(int af, const void *src, char *dst, size t size ); • opak k inet pton; vrac´ı dst nebo NULL (a nastav´ı errno) • pro obˇe vol´ an´ı plat´ı, ˇze af je AF INET nebo AF INET6

• Funkce jsou deklarované v arpa/inet.h. • inet pton vrac´ı 1 pokud konverze probˇehla, 0 pokud dan´ y ˇretˇezec nen´ı adresa dané adresn´ı rodiny, a -1 pokud af nen´ı podporováno (EAFNOSUPPORT). ym errno pokud ne. inet ntop vrac´ı dst pokud je vˇse OK a NULL s nastaven´ • Adresy i porty v bin´ arn´ı podobˇe jsou v s´ıt’ovém poˇrad´ı bajt˚ u, jak lze oˇcekávat. • dst mus´ı b´ yt dostateˇcnˇe velké, protoˇze zde nen´ı parametr specifikuj´ıc´ı velikost. To ale nen´ı problém, podle nastaven´ı af pouˇzijete konkrétn´ı adresn´ı strukturu nebo ˇretˇezec. Pro maximáln´ı postaˇcuj´ıc´ı velikost ˇretˇezc˚ u pro adresy norma definuje dvˇe makra, INET ADDRSTRLEN (16) a INET6 ADDRSTRLEN (48). Je to vˇcetnˇe m´ısta pro ukonˇcuj´ıc´ı \0. • size je velikost ˇretˇezce dst. Pokud nen´ı dostateˇcná, volán´ı selˇze s chybou ENOSPC. 190

• n je network, p je presentable • Pro IPv4 adresy se pouˇz´ıvala volán´ı inet aton a inet ntoa (a jako ascii). D´ıky nov´ ym vol´ an´ım jiˇz tyto funkce nen´ı potˇreba pouˇz´ıvat. Vˇsechna tato vol´ an´ı b´ yvaj´ı zdokumentov´ ana v manuálové stránce inet. • Uvˇedomte si, ˇze pomoc´ı tˇechto funkc´ı m˚ uˇzete pˇrevést najednou jen jeden typ, to je bud’ IPv4, anebo IPv6 adresu. Kdyˇz nev´ıte, co ˇcekat, zkus´ıte jednu a pokud to nevyjde, zkus´ıte druhou. Pˇr´ıklad: resolving/addresses.c .

Nav´ az´ an´ı spojen´ı: connect() int connect(int sock, struct sockaddr *address, socklen t address len); • nav´ aˇze spojen´ı lok´ aln´ıho soketu sock se vzdálen´ ym procesem, kter´ y pomoc´ı listen a accept ˇceká na spojen´ı na adrese address (o délce address len). • jestliˇze pro soket sock nebyla definována adresa volán´ım bind, je mu pˇriˇrazena nˇejak´ a nepouˇzitá adresa dle zvolené rodiny protokol˚ u. • pokud se spojen´ı nepovede, je soket v nedefinovaném stavu. Pˇred nov´ ym pokusem o spojen´ı by aplikace mˇela zavˇr´ıt deskriptor sock a vytvoˇrit nov´ y soket.

• Po u ´spˇeˇsném nav´ az´ an´ı spojen´ı mohou server i klient pro komunikaci pouˇz´ıvat bˇeˇzn´ a souborov´ a vol´ an´ı write a read, nebo funkce send, recv, sendmsg, recvmsg. Chov´ an´ı funkc´ı pro zápis a ˇcten´ı dat je podobné jako write a read pro roury. • Pˇr´ıklad: tcp/connect.c • I pro nespojované sluˇzby (UDP) se dá volat connect, t´ım se nenaváˇze spojen´ı, ale pouze se omez´ı adresa protistrany, se kterou je moˇzné pˇres soket komunikovat. Pro pos´ıl´ an´ı datagram˚ u se pak pouˇz´ıvaj´ı funkce send a recv, které uˇz nemaj´ı parametr pro adresu protistrany. Pro nespojované sluˇzby m˚ uˇzeme také volat connect() v´ıcekrát, kaˇzdé volán´ı novˇe nastav´ı adresu komunikuj´ıc´ı strany. Pokud pouˇzijeme m´ısto adresy NULL, nastaven´ı protistrany je zresetov´ ano. • Pokud je socket nastaven jako neblokuj´ıc´ı, viz strana 111, connect se nezablokuje ˇcek´ an´ım na spojen´ı. M´ısto toho vrát´ı -1 s errno nastavené na 191

EINPROGRESS (= “nebylo moˇzné vytvoˇrit spojen´ı okamˇzitˇe”), a ˇzádost o spojen´ı se uloˇz´ı do systémové fronty pro následné vyˇr´ızen´ı. Do té doby, neˇz je spojen´ı pˇripraveno, vol´ an´ı connect vrac´ı -1, nyn´ı ale s chybou EALREADY. Nen´ı ale takto vhodné testovat pˇripravenost spojen´ı, protoˇze pokud connect skonˇc´ı s chybou, dalˇs´ı vol´ an´ı connect provede nov´ y pokus o spojen´ı a jsme opˇet tam, kde jsme byli. . . Je moˇzné ale pouˇz´ıt select nebo poll pro ˇcekán´ı na z´ apis (ne ˇcten´ı) do socketu, viz strany 210, 213 které obsahuj´ı kompletn´ı pˇr´ıklad na neblokuj´ıc´ı connect, viz strana 211.

Pˇ rijet´ı zpr´ avy: recvfrom() ssize t recvfrom(int sock, void *buf, size t len, int flg, struct sockaddr *address, socklen t *address len ); • pˇrijme zpr´ avu ze soketu sock, uloˇz´ı ji do bufferu buf o velikosti len, do address d´ a adresu odes´ılatele zprávy, do address len délku adresy. Vr´ at´ı délku zprávy. Kdyˇz je zpráva delˇs´ı neˇz len, nadbyteˇcn´ a data se zahod´ı (SOCK STREAM nedˇel´ı data na zpr´ avy, data se nezahazuj´ı). • ve flg mohou b´ yt pˇr´ıznaky: ava se bere jako nepˇreˇctená, dalˇs´ı – MSG PEEK . . . zpr´ recvfrom ji vr´ at´ı znovu – MSG OOB . . . pˇreˇcte urgentn´ı (out-of-band) data y objem dat, – MSG WAITALL . . . ˇceká, dokud nen´ı naˇcten pln´ tj. len bajt˚ u

• pouˇz´ıv´ a se hlavnˇe pro sokety typu SOCK DGRAM. V takové situaci opˇet ˇceká na celou zpr´ avu, tj. nevr´ at´ı vám p˚ ulku datagramu. Opˇet je moˇzné nastavit socket jako neblokuj´ıc´ı. • address len mus´ı b´ yt inicializovaná velikost´ı bufferu, pokud nen´ı adresa NULL, ˇc´ımˇz ˇr´ık´ ate, ˇze v´ as adresa protistrany nezaj´ımá – tomu tak ale u datagram˚ u vetˇsinou nen´ı. • m´ısto recvfrom se d´ a pouˇz´ıt obecnˇejˇs´ı funkce recvmsg. • pro sokety, na které bylo voláno connect, se m´ısto funkce recvfrom volá recv. • po u ´speˇsném n´ avratu z recvfrom je moˇzné address a address len beze zmˇeny pouˇz´ıt pro n´ asledné volán´ı sendto. • stejnˇe jako sendto, je i recvfrom moˇzné pouˇz´ıt pro spojovanou sluˇzbu. Z´ıskat adresu protistrany je ale asi jednoduˇsˇs´ı pˇres volán´ı getpeername, viz strana 203. 192

• pˇr´ıklad: udp/udp-server.c

Posl´ an´ı zpr´ avy: sendto() ssize t sendto(int socket, void *msg, size t len, int flags, struct sockaddr *addr, socklen t addr len ); • prostˇrednictv´ım soketu socket poˇsle zprávu msg o délce len na adresu addr (o délce addr len). • parametr flags m˚ uˇze obsahovat pˇr´ıznaky: – MSG EOB . . . ukonˇcen´ı záznamu (pokud je podporováno protokolem) an´ı urgentn´ıch (out-of-band) dat, jejichˇz – MSG OOB . . . posl´ v´ yznam je z´ avisl´ y na protokolu

• Pouˇz´ıv´ a se hlavnˇe pro sokety typu SOCK DGRAM, protoˇze v této situaci máme pouze socket reprezentuj´ıc´ı naˇsi stranu spojen´ı; viz poznámka u slajdu k accept. Mus´ıme proto specifikovat adresu protistrany, coˇz volán´ım write nedok´ aˇzeme. Pro datagramovou sluˇzbu se nav´ıc data berou jako nedˇelitelná, tj. bud’ se akceptuj´ı cel´ a, nebo se volán´ı zablokuje – neexistuje ˇcásteˇcn´ y zápis. Stejnˇe jako je tomu u souborov´ ych deskriptor˚ u, je i zde moˇzné socket nastavit jako neblokuj´ıc´ı, viz strana 111. • M´ısto sendto se d´ a pouˇz´ıt obecnˇejˇs´ı funkce sendmsg. • Pro sokety, na které bylo vol´ ano connect, se m´ısto sendto m˚ uˇze pouˇz´ıt send. ´ eˇsn´ • Uspˇ y n´ avrat z libovolné funkce zapisuj´ıc´ı data do soketu neznamen´ a u ´ spˇ eˇ sn´ e doruˇ cen´ı zpr´ avy protistranˇ e, ale pouze uloˇzen´ı dat do lokáln´ıho bufferu odes´ılan´ ych dat. • Pokud pouˇzijete sendto na streamovanou sluˇzbu, je to moˇzné, ale adresa se ignoruje. Jedin´ y d˚ uvod proˇc nepouˇz´ıt pˇr´ımo write by tak byla moˇznost pouˇz´ıt flagy. V tom pˇr´ıpadˇe je ale jednoduˇsˇs´ı pouˇz´ıt send. • Pˇr´ıklad: udp/udp-client.c .

193

Uzavˇ ren´ı soketu: close() int close(int fildes); • zruˇs´ı deskriptor, pˇri zruˇsen´ı posledn´ıho deskriptoru soketu zavˇre soket. • pro SOCK STREAM soket záleˇz´ı na nastaven´ı pˇr´ıznaku SO LINGER (default je l onoff == 0, mˇen´ı se funkc´ı setsockopt). – l onoff == 0 . . . volán´ı close se vrát´ı, ale jádro se snaˇz´ı d´ al pˇrenést zbyl´ a data – l onoff == 1 && l linger != 0 . . . jádro se snaˇz´ı pˇrenést zbyl´ a data do vyprˇsen´ı timeoutu l linger v sekundách, kdyˇz se to nepovede, close vrát´ı chybu, jinak vrát´ı OK po pˇrenesen´ı dat. – l onoff == 1 && l linger == 0 . . . provede se reset spojen´ı

• po uzavˇren´ı m˚ uˇze TCP soket z˚ ustat po nˇejakou dobu v pˇrechodném stavu, kter´ y je definov´ an protokolem TCP pˇri ukonˇcován´ı spojen´ı. Neˇz je soket zcela zruˇsen, nelze pouˇz´ıt jin´ y soket na stejném portu, pokud toto nebylo pˇredt´ım povoleno nastaven´ım pˇr´ıznaku SO REUSEADDR pomoc´ı funkce setsockopt, viz strana 203. • reset spojen´ı je abnorm´ aln´ı ukonˇcen´ı spojen´ı. V TCP se pouˇzije paket s nastaven´ ym pˇr´ıznakem RST. Na druhé stranˇe se normáln´ı ukonˇcen´ı spojen´ı projev´ı jako konec souboru (pˇri ˇcten´ı), reset zp˚ usob´ı chybu ECONNRESET.

194

Uzavˇ ren´ı soketu: shutdown() int shutdown(int socket, int how ); • Uzavˇre soket (ale neruˇs´ı deskriptor) podle hodnoty how: – SHUT RD . . . pro ˇcten´ı – SHUT WR . . . pro z´ apis – SHUT RDWR . . . pro ˇcten´ı i zápis

• Po uzavˇren´ı soketu pomoc´ı shutdown je nutné zavˇr´ıt i deskriptor pomoc´ı close. • Pˇri norm´ aln´ım ukonˇcen´ı spojen´ı na u ´rovni protokolu TCP kaˇzdá strana signalizuje, ˇze uˇz nebude nic zapisovat. To plat´ı i v pˇr´ıpadˇe pouˇzit´ı close nebo shutdown(fd, SHUT RDWR). Pˇri pouˇzit´ı shutdown(fd, SHUT WR) lze ze soketu d´ al ˇc´ıst. Druh´ a strana dostane EOF pˇri ˇcten´ı, ale m˚ uˇze dál zapisovat.

195

Dalˇ s´ı funkce pro sokety int setsockopt(int socket, int level, int opt name, const void *opt value, socklen t option len ); • nastaven´ı parametr˚ u soketu int getsockopt(int socket, int level, int opt name, void *opt value, socklen t *option len ); • pˇreˇcten´ı parametr˚ u soketu int getsockname(int socket, struct sockaddr *address, socklen t *address len ); • zjiˇstˇen´ı (lok´ aln´ı) adresy soketu int getpeername(int socket, struct sockaddr *address, socklen t *address len ); • zjiˇstˇen´ı adresy vzd´ aleného soketu (druhého konce spojen´ı)

• hodnota level v getsockopt a setsockopt je obvykle SOL_SOCKET. U getsockopt, option len mus´ı b´ yt inicializována na velikost opt value. • funkce getsockname se pouˇz´ıvá, kdyˇz nevoláme bind a potˇrebujeme zjistit, jak´ a (lok´ aln´ı!) adresa byla j´ adrem soketu pˇridˇelena. • vol´ an´ı getsockopt(sock, SOL_SOCKET, SO_ERROR, &val, &len) vrát´ı (a vymaˇze) pˇr´ıznak chyby na soketu. Asi nejuˇziteˇcnˇejˇs´ı je pˇri zjiˇst’ován´ı, jak dopadl neblokuj´ıc´ı connect, viz strana 198. • pˇri pouˇzit´ı SO_REUSEADDR se dá po uzavˇren´ı poslouchaj´ıc´ıho serverového soketu znovu spustit server – volat socket, bind, listen a accept na stejné adrese a portu – i kdyˇz jeˇstˇe dob´ıhaj´ı spojen´ı vytvoˇrená pˇredchoz´ı instanc´ı serveru: int opt = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); • Pouˇzit´ı setsockopt s SO_REUSEADDR je vidˇet napˇr. v pˇr´ıkladu tcp/reuseaddr.c . Pozor na to, ˇze mus´ıte udˇelat alespoˇ n jedno spojen´ı, jinak systém nemá na co ˇcekat a opakovan´ y bind za sebou se podaˇr´ı i tak.

196

Poˇ rad´ı bajt˚ u • s´ıt’ové sluˇzby pouˇz´ıvaj´ı poˇrad´ı bajt˚ u, které se m˚ uˇze liˇsit od poˇrad´ı pouˇz´ıvaného na lokáln´ım systému. Pro pˇrevod lze pouˇz´ıt funkce (makra): – uint32 t htonl(uint32 t hostlong ); host → s´ıt’, 32 bit˚ u – uint16 t htons(uint16 t hostshort ); host → s´ıt’, 16 bit˚ u – uint32 t ntohl(uint32 t netlong ); s´ıt’ → host, 32 bit˚ u – uint16 t ntohs(uint16 t netshort ); s´ıt’ → host, 16 bit˚ u • s´ıt’ové poˇrad´ı bajt˚ u je big-endian, tj. nejprve vyˇsˇs´ı bajt. Pouˇz´ıvá se hlavnˇe ve funkc´ıch pracuj´ıc´ıch s adresami a ˇc´ısly port˚ u.

• pokud lok´ aln´ı systém pouˇz´ıvá stejné poˇrad´ı bajt˚ u jako s´ıt’, nedˇelaj´ı pˇrevodn´ı funkce nic. • jednoduch´ y a pˇritom vˇetˇsinou postaˇcuj´ıc´ı test na to, zda správnˇe pˇrevád´ıte poˇrad´ı bajt˚ u, je spustit vaˇs program proti sobˇe (pokud to tak lze) na architektur´ ach s rozd´ıln´ ym uspoˇra´dán´ım bajt˚ u.

197

ˇ ısla protokol˚ C´ u a port˚ u struct protoent *getprotobyname(const char *name ); • v poloˇzce p proto vr´ at´ı ˇc´ıslo protokolu se jménem name (napˇr. pro "tcp" vr´ at´ı 6). • ˇc´ısla protokol˚ u jsou uloˇzena v souboru /etc/protocols. struct servent *getservbyname(const char *name, const char *proto ); • pro zadané jméno sluˇzby name a jméno protokolu proto vrát´ı v poloˇzce s port ˇc´ıslo portu. • ˇc´ısla port˚ u jsou uloˇzena v souboru /etc/services. funkce vrac´ı NULL, kdyˇz v databázi nen´ı odpov´ıdaj´ıc´ı poloˇzka.

• v´ ysledek getprotobyname se hod´ı pro volán´ı socket, v´ ysledek getservbyname pro vol´ an´ı bind. • kromˇe getservbyname existuje jeˇstˇe getservbyport umoˇzn ˇuj´ıc´ı hledat sluˇzbu pomoc´ı ˇc´ısla portu (pozor, v network byte order !) a funkce getservent a spol. pro ruˇcn´ı proch´ azen´ı z´ aznam˚ u. • vˇsechny tyto funkce prohledávaj´ı pouze ”oficiáln´ı”seznamy sluˇzeb a protokol˚ u, které se nach´ azej´ı vˇetˇsinou v souborech zm´ınˇen´ ych na slajdu. • v uveden´ ych souborech je definováno mapován´ı mezi jmény a ˇc´ısly pro standardn´ı protokoly a sluˇzby. • pozor na to, ˇze protokolem zde nemysl´ıme HTTP, SSH, telnet nebo FTP – to jsou zde sluˇzby, reprezentované ˇc´ısly port˚ u. Protokol je TCP, UDP, OSPF, GRE apod., tedy to, co je pˇrenáˇseno v IP paketu v poloˇzce Protocol, viz strany 11 a 14 v RFC 791. • pˇr´ıklad: resolving/getbyname.c

198

Pˇ revod hostname na adresy: getaddrinfo() • ze zadan´ ych parametr˚ u pˇr´ımo generuje sockaddr struktury • pracuje s adresami i s porty • jej´ı chov´ an´ı je ovlivnitelné pomoc´ı tzv. hint˚ u int getaddrinfo(const char *nodename, const char *servicename, const struct addrinfo *hint, struct addrinfo **res ); • poloˇzky struktury addrinfo: ai flags (pro hinty), ai family (address family), ai socktype, ai protocol, ai addrlen, ysledné adresy), char struct sockaddr *ai addr (v´ *ai canonname, struct addrinfo *ai next (dalˇs´ı prvek v seznamu)

• Pˇri vyhodnocov´ an´ı dotaz˚ u na adresy a jména se pouˇz´ıvaj´ı jmenné sluˇzby podle konfigurace v souboru /etc/nsswitch.conf. • struktura addrinfo je definována v netdb.h • getaddrinfo um´ı do struktur sockaddr pˇrevádˇet jak ˇretˇezec kter´ y obsahuje hostname, tak ˇretˇezec obsahuj´ıc´ı IP adresu. Stejnˇe je tomu i pro porty. • funkce getaddrinfo vrac´ı parametrem res seznam struktur sockaddr, ve kter´ ych jsou uloˇzeny adresy koresponduj´ıc´ı k danému vstupu. • je rozd´ıl zda budou adresn´ı struktury dále pouˇzity pro server nebo klient; pro server napˇr. staˇc´ı jako nodename dát NULL (wildcard socket). Podobnˇe pro pro poloˇzku ai flags struktury addrinfo pouˇzité pro parametr hint a jej´ı hodnotu AI PASSIVE. • Po skonˇcen´ı pr´ ace s v´ ysledky nezapomeˇ nte zavolat funkci freeaddrinfo, kter´ a uvoln´ı naalokovanou pamˇet. • pˇr´ıklad: resolving/getaddrinfo.c • Dˇr´ıve se hodnˇe pouˇz´ıvaly funkce gethostbyname a gethostbyaddr. Tyto funkce pracuj´ı pouze s IPv4 adresami a jmény, jsou tak povaˇ zov´ any za zastaral´ e a jejich pouˇzit´ı se nedoporuˇcuje. M´ısto nich se doporuˇcuje pouˇz´ıvat obecnˇejˇs´ı vol´ an´ı getipnodebyname a getipnodebyaddr (getipnode* funkce se nach´ az´ı v r˚ uzn´ ych systémech, nicménˇe byly nedávno vyjmuty z GNU libc, takˇze se na jejich pˇr´ıtomnost nelze univerzálnˇe spolehnout. Nav´ıc nejsou souˇc´ ast´ı UNIX standardu.) resp. getaddrinfo, getnameinfo. Z tˇechto funkc´ı pouze getaddrinfo a getnameinfo splˇ nuj´ı standard (POSIX.1-2001). 199

• Pochopitelnˇe, je nutné dobˇre uváˇzit, zda existuj´ıc´ı kód pouˇz´ıvaj´ıc´ı legacy/obsolete funkce je potˇreba pˇrepisovat. Pokud takovému programu bude IPv4 staˇcit i nad´ ale, mˇenit existuj´ıc´ı a funkˇcn´ı kód nemus´ı b´ yt vˇzdy rozumné. Nov´ y k´ od ale vˇ zdy piˇ ste pomoc´ı nov´ ych funkc´ı, které podporuj´ı IPv4 i IPv6, i pokud byste si mysleli, ˇze v´ aˇs program nebude IPv6 nikdy pouˇz´ıvat. Za pouˇzit´ı gethostbyname, gethostbyaddr nebo struktur specifick´ ych pro IPv4 resp. IPv6 (bez v´ aˇzného d˚ uvodu) p˚ ujde u zkouˇsky hodnocen´ı dol˚ u.

Pˇ revod adresy na hostname: getnameinfo() • protˇejˇsek k funkci getaddrinfo • jako vstup pracuje s cel´ ymi sockaddr strukturami, tedy funguje s IPv4 i IPv6 adresami, narozd´ıl od funkce gethostbyaddr. int getnameinfo(const struct sockaddr *sa, socklen t *sa len, char *nodename, socketlen t *nodelen, char *servicename, socketlen t *servicelen, unsigned flags );

• getnameinfo prov´ ad´ı v jednom volán´ı funkce konverzi adresy a ˇc´ısla portu uloˇzen´ ych ve struktuˇre sockaddr na stringy v závislosti na namingov´ ych sluˇzb´ ach (tedy standardn´ı cesta pˇres naming backendy v /etc/nsswitch.conf) a hodnotˇe flags. Tedy to, co by bylo postaru nutné provádˇet pomoc´ı volán´ı gethostbyaddr a getservbyport. • Tato funkce je narozd´ıl od v´ yˇse zm´ınˇen´ ych legacy funkc´ı reentrantn´ı a hod´ı se tedy pro pouˇzit´ı v prostˇred´ı s thready (alespoˇ n na vˇetˇsinˇe systém˚ u). • manu´ alov´ a str´ anka obsahuje seznam pouˇziteln´ ych NI flag˚ u pro flags a jejich v´ yznam • pˇr´ıklad: resolving/getnameinfo.c

200

Pˇ r´ıklad: TCP server struct sockaddr storage ca; int nclients = 10, fd, nfd; struct addrinfo *r, *rorig, hi; memset(&hi, 0, sizeof (hi)); hi.ai family = AF UNSPEC; hi.ai socktype = SOCK STREAM; hi.ai flags = AI PASSIVE; getaddrinfo(NULL, portstr, &hi, &rorig); for (r = rorig; r != NULL; r = r->ai next) { fd = socket(r->ai family, r->ai socktype, r->ai protocol); if (!bind(fd, r->ai addr, r->ai addrlen)) break; } freeaddrinfo(rorig); listen(fd, nclients); for (;;) { sz = sizeof(ca); nfd = accept(fd, (struct sockaddr *)&ca, &sz); /* Komunikace s klientem */ close(newsock); }

• Toto je obecn´ a kostra serveru. Argument portstr je jedin´ y vstupn´ı parametr. Prvn´ı u ´spˇeˇsn´ y bind ukonˇc´ı procházen´ı seznamu adres. • Takto napsan´ y server bude na systému, kter´ y podporuje IPv6 i IPv4 pˇrij´ımat spojen´ı v obou adresn´ıch rodinách na tomtéˇz socketu. Spojen´ı z IPv4 klient˚ u budou m´ıt jako zdrojovou adresu tzv. IPv4-mapped IPv6 adresu, která v sobˇe obsahuje IPv4 adresu (napˇr. ::FFFF:78.128.192.1). • Vˇsimnˇete si, ˇze nen´ı nutné témˇeˇr nic pˇretypovávat na pointer na strukturu sockaddr. Jedinou v´ yjimkou je volán´ı accept. Pro volán´ı accept se pouˇz´ıv´ a struktura typu sockaddr storage coˇz je obecn´ y ”kontejner”schopn´ y pojmout prvky struktury sockaddr in i sockaddr in6. • socket a bind se volaj´ı pro vˇsechny vrácené sockaddr struktury dokud pro jednu z nich bind neuspˇeje nebo se seznam nevyˇcerpá. • Problém: nekontroluj´ı se nˇekteré návratové hodnoty a neobsahuje volán´ı uvolˇ nuj´ıc´ı alokované entity, napˇr. uzavˇren´ı socketu v pˇr´ıpadˇe chyby volán´ı bind. Stejnˇe tak se neˇreˇs´ı situace kdy se vyˇcerpá seznam bez toho aby bind uspˇel (to lze detekovat pomoc´ı kontroly nenulovosti pointeru r za koncem prvn´ıho cyklu).

201

Pˇ r´ıklad: TCP klient int fd; struct addrinfo *r, *rorig, hi; memset(&hi, 0, sizeof (hi)); hi.ai family = AF UNSPEC; hi.ai socktype = SOCK STREAM; getaddrinfo(hoststr, portstr, &hi, &r); for (rorig = r; r != NULL; r = r->ai next) { fd = socket(r->ai family, r->ai socktype, r->ai protocol); if (connect(fd, (struct sockaddr *)r->ai addr, r->ai addrlen) == 0) break; } freeaddrinfo(resorig); /* Komunikace se serverem */ close(fd);

• Toto je obecn´ a kostra TCP klienta. Argumenty hoststr a portstr jsou jediné vstupn´ı parametry. Prvn´ı u ´spˇeˇsn´ y connect ukonˇc´ı procházen´ı adres pro dan´ y host. • V pˇr´ıkladu vyuˇz´ıv´ ame automatického pˇridˇelen´ı volného portu systémem pˇri vol´ an´ı connect (nepˇredch´ azelo mu volán´ı bind). • postupnˇe se vol´ a connect na vˇsechny vrácené sockaddr struktury (v addrinfo struktur´ ach) pro dan´ y host do té doby, neˇz se podaˇr´ı spojit. • Problém: neobsahuje kontrolu návratov´ ych hodnot volán´ı. Stejnˇe tak se neˇreˇs´ı situace kdy se vyˇcerp´ a seznam bez toho aby connect uspˇel (to lze detekovat pomoc´ı kontroly nenulovosti pointeru r za koncem prvn´ıho cyklu). Nebo se neuzav´ır´ a socket pˇri ne´ uspˇeˇsném volán´ı connect, tj. je to file descriptor leak.

202

ˇ an´ı na data: select() Cek´ int select(int nfds, fd set *readfds, fd set *writefds, fd set *errorfds, struct timeval *timeout ); • zjist´ı, které ze zadan´ ych deskriptor˚ u jsou pˇripraveny pro ˇcten´ı, z´ apis, nebo na kter´ ych doˇslo k v´ yjimeˇcnému stavu. Pokud ˇz´ adn´ y takov´ y deskriptor nen´ı, ˇceká do vyprˇsen´ı ˇcasu timeout (NULL . . . ˇcek´ a se libovolnˇe dlouho). Parametr nfds udává rozsah testovan´ ych deskriptor˚ u (0, ..., nfds-1). • pro nastaven´ı a test masek deskriptor˚ u slouˇz´ı funkce: – void FD ZERO(fd set *fdset ) . . . inicializace – void FD SET(int fd, fd set *fdset ) . . . nastaven´ı – void FD CLR(int fd, fd set *fdset ) . . . zruˇsen´ı – int FD ISSET(int fd, fd set *fdset ) . . . test

• Motivace: jestliˇze chceme ˇc´ıst data z v´ıce deskriptor˚ u, je moˇzné, pokud jde o soubor, rovnou jej otevˇr´ıt s pˇr´ıznakem O NONBLOCK, anebo tento pˇr´ıznak kdykoli nastavit na deskriptoru pomoc´ı volán´ı fncnl s druh´ ym parametrem O SETFL (ne O SETFD, viz strana 111). Neblokuj´ıc´ım read pak stˇr´ıdavˇe testujeme jednotlivé deskriptory, a mezi kaˇzd´ ym kolem test˚ u tˇreba pouˇz´ıt sleep(1). Nev´ yhody jsou aktivn´ı ˇcekán´ı, reˇzie pˇrep´ınán´ı mezi módem uˇzivatelsk´ ym a j´ adra, moˇzn´ a prodleva (aˇz do délky vaˇseho ˇcekán´ı mezi jednotliv´ ymi koly), a také to, ˇze nesloˇz´ıte zkouˇsku (viz strana 173). Správné ˇreˇsen´ı této situace je pouˇz´ıt napˇr´ıklad select a následnˇe zavolat read na ty deskriptory, které vol´ an´ı select ohl´ as´ı jako pˇripravené. • Pˇr´ıklad na busy waiting: select/busy-wait.c . Vˇsimnˇete si, ˇze novˇe vytvoˇren´ y soket v pˇr´ıkladu je bez flagu O NONBLOCK, viz strana 196, takˇze je nutné flag nastavit. • Pˇripravený (ready) znamen´ a, ˇze read nebo write s vynulovan´ ym pˇr´ıznakem O NONBLOCK by se nezablokovalo, tedy ne nutnˇe ˇze nˇejaká data jsou pˇripravena (read napˇr. m˚ uˇze vr´ atit 0 pro end-of-file nebo -1 pro chybu) • Mnoˇzina errorfds je pro v´ yj´ımky v závislosti na typu deskriptoru; pro socket to je napˇr´ıklad pˇr´ıchod urgentn´ıch dat (flag URG v TCP hlaviˇcce). Neznamená to, ˇze na daném deskriptoru doˇslo k chybˇe ! Chyba s nastaven´ ym errno se zjist´ı z ostatn´ıch mnoˇzin po návratovém kódu -1 provedeného volán´ı, tj. napˇr´ıklad read. • Pˇri vol´ an´ı jsou v mnoˇzin´ ach deskriptory, které chceme testovat, po návratu z˚ ustanou nastavené jen ty deskriptory, na kter´ ych nastala testovaná událost. 203

Je nutn´ e je tedy pˇ red dalˇ s´ım vol´ an´ım select znovu nastavit. Typicky to jsou bitové masky, ale nemus´ı tomu b´ yt tak; z pozice programátora je to samozˇrejmˇe jedno. Proch´ azen´ı pˇres vrácené mnoˇziny je nutné dˇelat po jednom deskriptoru, pˇres FD ISSET. • Funkce select je pouˇziteln´ a i pro ˇcekán´ı na moˇznost zápisu do roury nebo soketu – ˇcek´ a se, aˇz druh´ a strana nˇeco pˇreˇcte a uvoln´ı se m´ısto v bufferu pro dalˇs´ı data. • M´ısto mnoˇziny pro deskriptory je moˇzné uvést NULL, speciáln´ı pˇr´ıpad pˇri nastaven´ı vˇsech mnoˇzin na NULL je volán´ı, které se pouze zablokuje do pˇr´ıchodu sign´ alu nebo do vyprˇsen´ı time-outu. • Po n´ avratu je nutné otestovat kaˇzd´ y deskriptor zvláˇst’, nen´ı k dispozici volán´ı, které by v´ am vytvoˇrilo mnoˇzinu pˇripraven´ ych deskriptor˚ u. • Pokud obsluhuje s´ıt’ov´ y server v´ıce port˚ u, m˚ uˇze volat select na pˇr´ısluˇsné deskriptory soket˚ u a n´ aslednˇe accept na deskriptory, pro které select ohlásil pˇr´ıchod ˇz´ adosti klienta (pˇripravenost ke ˇcten´ı). • Vol´ an´ı connect na neblokuj´ıc´ım soketu se hned vrát´ı, navázán´ı spojen´ı ohlás´ı n´ asledn´ y select jako pˇripravenost k zápisu. V´ıce viz strana 198. • Dalˇs´ı moˇznost pouˇzit´ı select je s´ıt’ov´ y server, kter´ y v jednom procesu obsluhuje paralelnˇe nˇekolik klient˚ u. Pomoc´ı select se testuje stav deskriptor˚ u odpov´ıdaj´ıc´ıch spojen´ı s jednotliv´ ymi klienty a pˇres deskriptory pˇripravené pro ˇcten´ı/z´ apis se komunikuje. Aby se mohli pˇripojovat nov´ı klienti, testuje se i deskriptor soketu, kter´ y se pouˇz´ıvá pro accept. Vyuˇz´ıvá se toho, ˇze select ohl´ as´ı deskriptor s ˇcekaj´ıc´ı ˇz´ adost´ı klienta o spojen´ı jako pˇripraven´ y pro ˇcten´ı. Na takov´ y deskriptor je moˇzné volat accept. • Pozor na to, ˇze select m˚ uˇ ze zmˇenit strukturu timeval, existuje nové volán´ı pselect, které kromˇe dalˇs´ıch zmˇen strukturu pro timeout nezmˇen´ı. • Pro nfds je moˇzné pouˇz´ıt FD SETSIZE, coˇz je systémová konstanta pro maxim´ aln´ı poˇcet deskriptor˚ u. Nen´ı to ale nejlepˇs´ı ˇreˇsen´ı, protoˇze tato konstanta je sice vˇetˇsinou jen 1024 na 32-bitov´ ych systémech, na Solarisu to vˇsak pro 64-bitové architektury je uˇz 65536. Pˇredpokládám podobné chován´ı i pro ostatn´ı systémy. • Pokud se ˇcas nastav´ı na 0, tedy ted’ nemluv´ıme o nastaven´ı ukazatele na NULL, select se d´ a pouˇz´ıt pro tzv. polling – zjist´ı souˇcasn´ y stav a hned se vr´ at´ı. • Pˇr´ıklad: select/select.c • select lze pouˇz´ıt na zjiˇst’ov´ an´ı stavu po volán´ı connect na neblokuj´ıc´ı socket. Zda spojen´ı probˇehlo u ´spˇeˇsnˇe se dozv´ıte z funkce getsockopt s opt name nastaven´ ym na SO ERROR, viz strana 203. Pˇr´ıklad: tcp/non-blocking-connect.c .

204

Pˇ r´ıklad: pouˇ zit´ı select() • Deskriptor fd odkazuje na soket, pˇrepisuje s´ıt’ovou komunikaci na termin´ al a naopak. int sz; fd set rfdset, efdset; char buf[BUFSZ]; for(;;) { FD ZERO(&rfdset); FD SET(0, &rfdset); FD SET(fd, &rfdset); efdset = rfdset; select(fd+1, &rfdset, NULL, &efdset, NULL); if(FD ISSET(0, &efdset)) /* V´ yjimka na stdin */ ; if(FD ISSET(fd, &efdset)) /* V´ yjimka na fd */ ; if(FD ISSET(0, &rfdset)) sz = read(0, buf, BUFSZ); write(fd, buf, sz); if(FD ISSET(fd, &rfdset)) sz = read(fd, buf, BUFSZ); write(1,buf,sz); }

• Zde je typické pouˇzit´ı select, kdy je tˇreba ˇc´ıst data souˇcasnˇe ze dvou zdroj˚ u. Tento pˇr´ıklad pˇredpokl´ ad´ a, ˇze deskriptory 0 a fd jsou nastaveny jako neblokuj´ıc´ı. • Pˇred kaˇzd´ ym vol´ an´ım select se mus´ı znovu nastavit mnoˇziny deskriptor˚ u. • Lepˇs´ı ˇreˇsen´ı je pouˇz´ıt select i na zápis. Logika ˇr´ızen´ı je pak taková, ˇze pro kaˇzd´ y smˇer datové komunikace máme samostatn´ y buffer. Pˇr´ısluˇsn´ y ˇctec´ı deskriptor bude v mnoˇzinˇe pro ˇcten´ı v select, právˇe kdyˇz je buffer prázdn´ y. Naopak z´ apisov´ y deskriptor bude v mnoˇzinˇe pro zápis, právˇe kdyˇz je buffer nepr´ azdn´ y. • select usp´ı proces i pˇri kontrole pˇripravenosti k zápisu, pokud data nejsou z druhé strany ˇctena. To jde jednoduˇse nasimulovat pomoc´ı programu, kter´ y se jen pˇripoj´ı (provede TCP handshake), ale nic neˇcte. Viz pˇr´ıklad a komentáˇr v select/write-select.c .

205

ˇ an´ı na data: poll() Cek´ int poll(struct pollfd fds [], nfds t nfds, int timeout ); • ˇcek´ a na ud´ alost na nˇekterém z deskriptor˚ u v poli fds o nfds prvc´ıch po dobu timeout ms (0 . . . vrát´ı se hned, -1 . . . ˇceká se libovolnˇe dlouho). • prvky struktury pollfd: – fd . . . ˇc´ıslo deskriptoru – events . . . oˇcek´ avané události, OR-kombinace POLLIN (lze ˇc´ıst), POLLOUT (lze psát), atd. – revents . . . ud´ alosti, které nastaly, pˇr´ıznaky jako v events, nav´ıc napˇr. POLLERR (nastala chyba)

• Tato funkce je obdoba vol´ an´ı select. • argument timeout je v milisekundách • Existuj´ıc´ıch pˇr´ıznak˚ u pro pouˇzit´ı je mnohem v´ıce, viz manuálová stránka. • Na Solarisu je poll systémové volán´ı, select pak knihovn´ı funkce implementovan´ a pomoc´ı poll, a poll je tam preferováno. poll je nutné pouˇz´ıt v pˇr´ıpadˇe, ˇze chcete testovat deskriptor vˇetˇs´ı nebo rovn´ y FD SETSIZE. To je hlavn´ı rozd´ıl mezi vol´ an´ımi select a poll. Dalˇs´ı rozd´ıl je ten, ˇze nen´ı tˇreba nastavovat deskriptory po kaˇzdém volán´ı poll, ani nulovat revents. ˇ nastaven´ • Cas y na -1 je to samé jako NULL u select. • Pokud nastav´ıte poˇcet deskriptor˚ u na 0 (a mˇeli byste pak pro fds pouˇz´ıt NULL), m˚ uˇzete poll jednoduˇse vyuˇz´ıt pro ˇcekán´ı s menˇs´ı granularitou neˇz po sekund´ ach nab´ızené vol´ an´ım sleep. Pˇr´ıklad: sleep/poll-sleep.c – Mimochodem, jin´ y zp˚ usob, jak dosáhnout menˇs´ı granularity neˇz je jedna sekunda je vol´ an´ı nanosleep, které je ale definované rozˇs´ıˇren´ım POSIX.4 a tedy nemus´ı b´ yt vˇzdy k dispozici. Pˇr´ıklad: sleep/nanosleep.c .

206

Spr´ ava s´ıt’ov´ ych sluˇ zeb: inetd • servery s´ıt’ov´ ych sluˇzeb se spouˇst´ı bud’ pˇri startu systému, nebo je startuje démon inetd pˇri pˇripojen´ı klienta. • démon inetd ˇcek´ a na portech definovan´ ych v /etc/inetd.conf a kdyˇz detekuje pˇripojen´ı klienta, naváˇze spojen´ı, spust´ı pˇr´ısluˇsn´ y server a pˇresmˇeruje mu deskriptory 0, 1 a 2 do soketu, pˇres kter´ y lze komunikovat s klientem. • pˇr´ıklad obsahu /etc/inetd.conf: ftp stream tcp nowait root /usr/etc/ftpd ftpd -l shell stream tcp nowait root /usr/etc/rshd rshd -L login stream tcp nowait root /usr/etc/rlogind rlogind exec stream tcp nowait root /usr/etc/rexecd rexecd finger stream tcp nowait guest /usr/etc/fingerd fingerd ntalk dgram udp wait root /usr/etc/talkd talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal

• inetd je v podstatˇe velk´ y poll cyklus obhospodaˇruj´ıc´ı sadu socket˚ u podle konfigurace. • Start pˇres inetd ˇsetˇr´ı prostˇredky, protoˇze pˇr´ısluˇsn´ y server bˇeˇz´ı pouze po ˇcas, kdy jsou jeho sluˇzby opravdu potˇreba. Nehod´ı se tedy pro pro spoustˇen´ı vyt´ıˇzen´ ych sluˇzeb (HTTP) nebo sluˇzeb kde m˚ uˇze b´ yt velk´ y overhead pˇri inicializaci (napˇr. SSH). • Typicky se pomoc´ı inetd spouˇst´ı servery, které se pouˇz´ıvaj´ı málo nebo jejichˇz inicializace je relativnˇe nen´ aroˇcná (telnetd, ftpd). Silnˇe vyt´ıˇzené a dlouho startuj´ıc´ı servery (httpd) se obvykle startuj´ı ze systémov´ ych inicializaˇcn´ıch skript˚ u a bˇeˇz´ı st´ ale. ˇ • Casto m´ a cenu m´ıt inetd vypnut´ yu ´plnˇe. Pokud na vaˇsem stroji bˇeˇz´ı napˇr. pouze SSH, tak pro to se inetd ve vˇetˇsinˇe pˇr´ıpad˚ u nepouˇz´ıvá, inetd by byl jen dalˇs´ım serverem bˇeˇz´ıc´ım na stroji a zdroj potenciáln´ıho nebezpeˇc´ı, pokud by se v nˇem nebo v jednom z nˇej spouˇstˇen´ ych program˚ u objevila bezpeˇcnostn´ı chyba. To by ostatnˇe mˇelo platit pro vˇsechny instalované programy poskytuj´ıc´ı s´ıt’ové sluˇzby - bud’to by mˇely implicitnˇe poslouchat pouze na localhostu (resp. pouˇz´ıvat unixové sockety) nebo by implicitnˇe nemˇely bˇeˇzet a mˇely by b´ yt spuˇstˇeny (ve smyslu permanentnˇe zapnuty) aˇz tehdy kdyˇz jsou skuteˇcnˇe tˇreba (tento pˇr´ıstup se oznaˇcuje jako secure by default).

207

Form´ at souboru /etc/inetd.conf sluˇ zba soket proto ˇ cek´ an´ ı uˇ ziv server argumenty • sluˇ zba . . . jméno s´ıt’ové sluˇzby podle /etc/services • soket . . . stream nebo dgram • proto . . . komunikaˇcn´ı protokol (tcp, udp) • c ˇek´ an´ ı . . . wait (inetd ˇceká na ukonˇcen´ı serveru pˇred akceptov´ an´ım dalˇs´ıho klienta), nowait (inetd akceptuje dalˇs´ıho klienta hned) • uˇ zivatel . . . server pobˇeˇz´ı s identitou tohoto uˇzivatele • server . . . u ´pln´ a cesta k programu serveru nebo internal ’ (sluˇzbu zajiˇst uje inetd) • argumenty . . . pˇr´ıkazov´ y ˇrádek pro server, vˇcetnˇe argv[0]

• Soket typu stream: – wait . . . server dostane soket, na kter´ y mus´ı aspoˇ n jednou zavolat accept. Teprve t´ım z´ıská nov´ y soket, pˇres kter´ y m˚ uˇze komunikovat s klientem. Po skonˇcen´ı serveru pˇreb´ırá ˇr´ızen´ı soketu zpˇet inetd. – nowait . . . inetd zavolá accept a z´ıskan´ y soket pˇredá serveru, server tedy m˚ uˇze rovnou komunikovat (m˚ uˇze pouˇz´ıvat standardn´ı vstup a v´ ystup) a nemus´ı vˇedˇet, ˇze komunikuje po s´ıti. Mezit´ım inetd ˇceká na dalˇs´ı klienty a podle potˇreby spouˇst´ı dalˇs´ı instance serveru. • Jak pro wait tak pro nowait provedl inetd na soketu volán´ı bind aby mu pˇriˇradil ˇc´ıslo portu podle pole sluˇ zba. • V pˇr´ıpadˇe wait dostane server soket od inetd v podobˇe deskriptoru 0 (standarn´ı vstup). inetd pˇred volán´ım fork provedl dup2(sock, 0), kde sock je nabindovan´ y socket. Viz pˇr´ıklad inetd/accept-rw.c . • Pro soket typu dgram m´ a smysl pouze wait. Server mus´ı pˇreˇc´ıst ze soketu aspoˇ n jeden datagram. • Jestliˇze inetd restartuje server (kromˇe stream nowait) pˇr´ıliˇs ˇcasto (cca jednou za sekundu), usoud´ı, ˇze nastala chyba a po urˇcitou dobu (asi 10 minut) sluˇzbu zablokuje (nespouˇst´ı server a odm´ıtá spojen´ı). Ostatn´ı servery spouˇst´ı norm´ alnˇe d´ al. • Pˇr´ıklad: inetd/echo-server.sh . Pod´ıvejte se do daného skriptu pro podrobné instrukce, jak ho pouˇz´ıt. 208

• Pro zaj´ımavost, ne vˇsechny systémy mus´ı nutnˇe inetd.conf pouˇz´ıvat stejn´ ym zp˚ usobem. Napˇr´ıklad od Solarisu 10 se tento soubor pouˇzije pouze pro poˇc´ ateˇcn´ı konverzi do intern´ı databáze pomoc´ı inetconv(1M) a pro zap´ınán´ı a vyp´ın´ an´ı sluˇzeb se pak pouˇz´ıvá pˇr´ıkaz inetadm(1M).

Obsah • u ´vod, v´ yvoj UNIXu a C, programátorské nástroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupov´ a pr´ ava, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definov´ ano pozdˇeji, podle toho kolik zbyde ˇcasu

209

Vl´ akna • vl´ akno (thread ) = linie v´ ypoˇctu (thread of execution) • vl´ akna umoˇzn ˇuj´ı m´ıt v´ıce lini´ı v´ ypoˇctu v rámci jednoho procesu • klasick´ y unixov´ y model: jednovláknové procesy • vl´ akna nejsou vhodn´ a pro vˇsechny aplikace • v´ yhody vl´ aken: – zrychlen´ı aplikace, typicky na v´ıceprocesorech (vlákna jednoho procesu mohou bˇeˇzet souˇcasnˇe na r˚ uzn´ ych procesorech) – modul´ arn´ı programován´ı • nev´ yhody vl´ aken: – nen´ı jednoduché korektnˇe napsat sloˇzitˇejˇs´ı kód s vlákny – obt´ıˇznˇejˇs´ı debugging

• Pro aplikace, kde kaˇzd´ y krok závis´ı na kroku pˇredcházej´ıc´ım, nemaj´ı vlákna pˇr´ıliˇs velk´ y smysl. • Debuggery typicky maj´ı podporu vláken, ale debugging zmˇen´ı timing, takˇze to co v re´ alu dˇel´ a problém se pˇri debuggingu v˚ ubec nemus´ı projevit. Toto vˇetˇsinou nen´ı problémem u klasick´ ych 1-vláknov´ ych proces˚ u. • Jak bylo uvedeno na slajdech s doporuˇcenou literaturou, k vlákn˚ um existuje v´ yborn´ a kniha [Butenhof]. On-line pak je tˇreba dostupná obsáhlá kniha Multithreaded Programming Guide na http://docs.oracle.com. • Dalˇs´ı situac´ı, kdy je potˇreba z˚ ustat u pouˇzit´ı proces˚ u, je pokud je nutné vytvoˇren´ ym proces˚ um mˇenit re´ alné a efektivn´ı UID. To je tˇreba pˇr´ıpad OpenSSH, kde se pro kaˇzdé spojen´ı vytvoˇr´ı dva server procesy. Jeden proces bˇeˇz´ı s maxim´ aln´ımi privilegii, typicky jako root, a poskytuje sluˇzby neprivilegovanému procesu bˇeˇz´ıc´ım pod pˇrihl´ aˇsen´ ym uˇzivatelem. Takovou sluˇzbou je tˇreba alokace presudo termin´ alu, coˇz pod bˇeˇzn´ ym uˇzivatelem nelze provést. Idea je takov´ a, ˇze vˇetˇsina k´ odu privilegia roota nepotˇrebuje, ˇc´ımˇz se v´ yraznˇe zmenˇs´ı mnoˇzstv´ı k´ odu, kde by chyba vedla k z´ıskán´ı privilegi´ı roota. Tento zp˚ usob se naz´ yv´ a privilege separation a nen´ı moˇzné ho dosáhnout pomoc´ı vláken tak, ˇze by r˚ uzn´ a vl´ akna bˇeˇzela pod r˚ uzn´ ymi uˇzivateli, protoˇze vˇsechna vlákna sd´ılej´ı stejn´ y adresov´ y prostor, a kaˇzdé ho tak m˚ uˇze mˇenit.

210

Implementace vl´ aken library-thread model • vl´ akna jsou implementována v knihovnách, jádro je nevid´ı. • run-time knihovna plánuje vlákna na procesy a jádro pl´ anuje procesy na procesory. ⊕ menˇs´ı reˇzie pˇrep´ın´ an´ı kontextu nem˚ uˇze bˇeˇzet v´ıce vláken stejného procesu najednou. kernel-thread model • vl´ akna jsou implementována pˇr´ımo jádrem. ⊕ v´ıce vl´ aken jednoho procesu m˚ uˇze bˇeˇzet najednou na r˚ uzn´ ych procesorech. pl´ anov´ an´ı thread˚ u pouˇz´ıvá systémová volán´ı m´ısto knihovn´ıch funkc´ı, t´ım v´ıce zatˇeˇzuje systém. hybridn´ı modely • vl´ akna se multiplexuj´ı na nˇekolik jádrem plánovan´ ych entit.

• p˚ uvodnˇe UNIX s vl´ akny nepracoval a prvn´ı implementace byly ˇcistˇe knihovn´ı, bez u ´ˇcasti j´ adra. Dnes se pouˇz´ıvá sp´ıˇse implementace vláken v jádru nebo sm´ıˇsen´ y model. • zat´ımco pˇ ri pr´ aci s v´ıce procesy je nutn´ e vyvinout jist´ eu ´ sil´ı proto, aby dan´ e procesy mohly data sd´ılet, u vl´ aken je naopak nutn´ eˇ reˇ sit situaci, jak pˇ rirozen´ e sd´ılen´ı dat uhl´ıdat. • vl´ akna implementov´ ana pouze v knihovnˇe mohou b´ yt preemptivn´ı i nepreemptivn´ı. Pro preemptivnost je moˇzné pouˇz´ıt ˇcasovaˇce a signály. Pokud multithreading (= pouˇzit´ı vl´ aken v aplikaci) nen´ı pouˇzit pro zv´ yˇsen´ı v´ ykonu aplikace, typicky nen´ı problém s pouˇzit´ım nepreemptivn´ıch vláken. Stˇr´ıdán´ı vl´ aken se automaticky dos´ ahne pouˇz´ıván´ım blokuj´ıc´ıch systémov´ ych volán´ı. • pokud se vol´ an´ı v library-thread modelu zablokuje, zablokuje se cel´ y proces, tj. ˇz´ adné vl´ akno nem˚ uˇze bˇeˇzet. To vypl´ yvá z toho, ˇze jádro v tomto modelu o pojmu vl´ akno nic nev´ı. Knihovn´ı funkce jsou proto pˇrepsány tak, ˇze m´ısto blokuj´ıc´ıch vol´ an´ı se pouˇzij´ı neblokuj´ıc´ı, aktuáln´ı kontext se uloˇz´ı a n´ aslednˇe pˇrepne na jiné vl´ akno pomoc´ı volán´ı setjmp a longjmp. Pˇr´ıklad: pthreads/setjmp.c .

211

POSIX vl´ akna (pthreads) • definované rozˇs´ıˇren´ım POSIX.1c • vol´ an´ı t´ ykaj´ıc´ı se vl´ aken zaˇc´ınaj´ı prefixem pthread • tyto funkce vrac´ı 0 (OK) nebo pˇr´ımo ˇc´ıslo chyby – . . . a nenastavuj´ı errno! – nelze s nimi proto pouˇz´ıt funkce perror nebo err • POSIX.1c definuje i dalˇs´ı funkce, napˇr´ıklad nové verze k tˇem, které nebylo moˇzné upravit pro pouˇzit´ı ve vláknech bez zmˇeny API, napˇr readdir r, strtok r, atd. – r znamen´ a reentrant, tedy ˇze funkci m˚ uˇze volat v´ıce vláken najednou bez vedlejˇs´ıch efekt˚ u

• Obecné informace o POSIXu jsou na stranˇe 16. • Existuj´ı i dalˇs´ı implementace vláken podporuj´ıc´ı rozd´ılná API, napˇr. systémové vol´ an´ı sproc() v IRIXu, Cthreads, Solaris threads, . . . • API pro POSIX vl´ akna jsou na r˚ uzn´ ych systémech k dispozici v r˚ uzn´ ych knihovn´ ach. Napˇr. na Linuxu je nutné programy pouˇz´ıvaj´ıc´ı POSIX threads API linkovat s -lpthread, na Solarisu jsou funkce souˇcást´ı libc. • Implementace POSIX threads je vˇetˇsinou postavena nad nativn´ı implementac´ı thread˚ u na daném systému, napˇr. na Solarisu nad funkcemi s prefixem thr . • O reentrantn´ıch funkc´ıch ve spojen´ı s vlákny v´ıce na stranˇe 247 • Co se t´ yk´ a oˇsetˇren´ı n´ avratov´ ych hodnot pthread funkc´ı, tak vzhledem k tomu, ˇze nenastavuj´ı errno, nen´ı následuj´ıc´ı kód napsán korektnˇe: if (pthread_create(&thr, NULL, thrfn, NULL) != 0) err(1, "pthread_create"); protoˇze program v´ am pˇri chybˇe vyp´ıˇse nˇeco jako: – “a.out: pthread create: Error 0” na Solarisu – “a.out: pthread create: Success” na Linuxov´ ych distribuc´ıch – “a.out: pthread create: Unknown error: 0” na FreeBSD

212

– nebo nˇeco jiného, podle systému, kter´ y zrovna pouˇz´ıváte Trochu matouc´ı mi pˇrijde pˇr´ıstup Linuxu, protoˇze na prvn´ı pohled nen´ı jasné, co se vlastnˇe stalo a ˇze errno bylo nulové. Nicménˇe, správnˇe napsan´ y kód je napˇr´ıklad tento: int e; if ((e = pthread_create(&thr, NULL, thrfn, NULL)) != 0) errx(1, "pthread_create: %s", strerror(e)); Vˇsimnˇete si nutnosti pouˇz´ıt errx funkci, ne err, protoˇze ta internˇe pracuje s errno. Pozor na to, ˇze promˇenná errno by v˚ ubec nemusela b´ yt nulová, pokud by ji nastavila jin´ a funkce volaná pˇred pthread create, coˇz by mohlo uˇzivatele nebo program´ atora zmást jeˇstˇe v´ıce. • Ostatn´ı funkce, které errno nastavuj´ı, funguj´ı stejnˇe i s vlákny, tj. kaˇzdé vl´ akno m´ a svoj´ı errno. Pozor je ale tˇreba dát na to, ˇze r˚ uzné systémy se chovaj´ı r˚ uznˇe. Na Linuxu je errno automaticky thread-safe protoˇze tam mus´ıte specifikovat vl´ aknovou knihovnu, na Solarisu ale mus´ıte u Sun Studia pouˇz´ıt pˇrep´ınaˇc -mt nebo -D REENTRANT, viz manuálová stránka threads(5). Pokud tak neudˇel´ ate, nebude errno nastaveno korektnˇe. Pod´ıvejte se na definici errno v /usr/include/errno.h a pochop´ıte, jak to funguje. Dalˇs´ı rozd´ıl je ten, ˇze Solaris m´ a vlákna pˇr´ımo v libc, u ostatn´ıch systém˚ u mus´ıte vˇetˇsinout specifikovat vl´ aknovou knihovnu. U gcc staˇc´ı na jakémkoli systému pouˇz´ıt pˇrep´ınaˇc -pthreads, potˇrebnou knihovnu si pˇrekladaˇc uˇz najde sám, a z´ aroveˇ n nastav´ı errno jako thread-safe. Stejnˇe jako u cc je ale na Solarisu moˇzné pouˇz´ıt jen -D REENTRANT.

Vytvoˇ ren´ı vl´ akna int pthread create(pthread t *thread, const pthread attr t *attr, void *(*start fun )(void*), void *arg ); • vytvoˇr´ı nové vl´ akno, do thread uloˇz´ı jeho ID. • podle attr nastav´ı jeho atributy, napˇr. velikost zásobn´ıku ˇci pl´ anovac´ı politiku. NULL znamená pouˇz´ıt implicitn´ı atributy. • ve vytvoˇreném vl´ aknu spust´ı funkci start fun() s argumentem arg. Po n´ avratu z této funkce se zruˇs´ı vlákno. • s objekty pthread attr t lze manipulovat funkcemi pthread attr init(), pthread attr destroy(), pthread attr setstackaddr(), atd. . .

213

• Pozor na konstrukce typu: for (i = 0; i < N; i++) pthread create(&tid, attr, start routine, &i); Na prvn´ı pohled takto pˇred´ ame kaˇzdému vláknu jeho index. Jenˇze plánovaˇc m˚ uˇze zp˚ usobit to, ˇze neˇz si novˇe spuˇstˇené vlákno staˇc´ı pˇreˇc´ıst hodnotu i, pˇr´ıkaz for provede dalˇs´ı iteraci a hodnota se zmˇen´ı. Obecnˇe vlákno m˚ uˇze dostat m´ısto spr´ avné hodnoty i libovolnou vˇetˇs´ı. • Pˇr´ıklady: pthreads/wrong-use-of-arg.c , pthreads/correct-use-of-arg.c . • Co je moˇzné pouˇz´ıt, pokud potˇrebujeme pˇredat pouze jednu hodnotu (podle C standardu je to ale implementaˇ cnˇ e z´ avisl´ e a tedy nepˇ renositeln´ e): assert(sizeof (void *) >= sizeof (int)); for (i = 0; i < N; i++) pthread create(&tid, attr, start routine, (void *)(intptr t)i); . . . a ve funkci void *start routine(void *arg) pak pˇretypovat ukazatel zp´ atky na integer a m´ ame potˇrebn´ y identifikátor vlákna: printf("thread %d started\n", (int)arg); Pˇr´ıklad: pthreads/int-as-arg.c • Pokud potˇrebujeme pˇredat v´ıce bajt˚ u neˇz je velikost ukazatele, tak uˇz opravdu mus´ıme pˇredat ukazatel na pamˇet’ s pˇr´ısluˇsn´ ymi pˇredávan´ ymi daty nebo pouˇz´ıt glob´ aln´ı promˇenné; pˇr´ıstup k nim je pak ale samozˇrejmˇe nutné synchronizovat. uhledn´ y”typ, do kterého program nevid´ı a ani by nemˇel, • pthread t je ”pr˚ jeho implementace se m˚ uˇze liˇsit systém od systému; nicménˇe vˇetˇsinou jde o celoˇc´ıseln´ y typ, kter´ y se pouˇz´ıvá k mapován´ı na nativn´ı thready na daném systému. Pˇri vytv´ aˇren´ı nˇekolika thread˚ u v cyklu je tedy nutné pˇredat funkci pthread create pokaˇzdé adresu jiné promˇenné pthread t, jinak uˇz nep˚ ujde s tˇemito vl´ akny nad´ ale manipulovat z hlavn´ıho vlákna, napˇr. ˇcekat na jejich dokonˇcen´ı (aˇckoliv bˇeˇzet budou normálnˇe), jejich identifikace se ztrat´ı. Toto je ˇreˇsitelné napˇr. pˇres pole pthread t nebo dynamickou alokac´ı.

214

Soukrom´ e atributy vl´ aken • ˇc´ıtaˇc instrukc´ı • z´ asobn´ık (automatické promˇenné) • thread ID, dostupné funkc´ı pthread t pthread self(void); • pl´ anovac´ı priorita a politika • hodnota errno • kl´ıˇcované hodnoty – dvojice (pthread key t key, void *ptr ) – kl´ıˇc vytvoˇren´ y vol´ an´ım pthread key create() je viditeln´ y ve vˇsech vl´ aknech procesu. – v kaˇzdém vl´ aknu m˚ uˇze b´ yt s kl´ıˇcem asociována jiná hodnota vol´ an´ım pthread setspecific().

• Kaˇzdé vl´ akno m´ a z´ asobn´ık pevné velikosti, kter´ y se automaticky nezvˇ etˇ suje. B´ yv´ a to kolem 64-512 KB, takˇze pokud si ve funkci alokujete pole o velikosti 256KB a pouˇzijete ho, je dost moˇzné, ˇze skonˇc´ıte s core dumpem. Pokud chcete z´ asobn´ık vˇetˇs´ı neˇz je systémov´ y default, mus´ıte pouˇz´ıt argument attr pˇri vytvoˇren´ı vl´ akna. Pˇr´ıklad: pthreads/pthread-stack-overflow.c • O soukrom´ ych kl´ıˇcovan´ ych atributech vlákna v´ıce na stranˇe 227. • Kaˇzdé vl´ akno m´ a jeˇstˇe vlastn´ı signálovou masku, k tomu se také dostaneme, viz strana 230.

215

Ukonˇ cen´ı vl´ akna void pthread exit(void *val ptr ); • ukonˇc´ı volaj´ıc´ı vl´ akno, je to obdoba exit pro proces int pthread join(pthread t thr, void **val ptr ); • poˇck´ a na ukonˇcen´ı vl´ akna thr a ve val ptr vrát´ı hodnotu ukazatele z pthread exit nebo návratovou hodnotu vláknové funkce. Pokud vl´ akno skonˇcilo dˇr´ıve, funkce hned vrac´ı pˇr´ısluˇsnˇe nastavené val ptr. • obdoba ˇcek´ an´ı na synovsk´ y proces pomoc´ı wait int pthread detach(pthread t thr ); • nastav´ı okamˇzité uvolnˇen´ı pamˇeti po ukonˇcen´ı vlákna, na vl´ akno nelze pouˇz´ıt pthread join.

• Pokud se nepouˇzije pthread exit, vyvolá se tato funkce pˇri skonˇcen´ı vlákna implicitnˇe, s hodnotou pouˇzitou pro return • Norma specifikuje, ˇze stav z´ asobn´ıku ukonˇcovaného vlákna nen´ı definovan´ y, a proto by se v pthread exit nemˇely pouˇz´ıvat odkazy na lokáln´ı promˇenné ukonˇcovaného vl´ akna pro parametr val ptr • Pokud nem´ ame v u ´myslu po skonˇcen´ı vlákna volat pthread join, je tˇreba zavolat pthread detach. Jinak po ukonˇceném vláknu z˚ ustanou v pamˇeti data nutn´ a pro zjiˇstˇen´ı jeho v´ ysledku pomoc´ı pthread join. To je podobná situace, jako kdyˇz rodiˇcovsk´ y proces nepouˇz´ıvá wait a v systému se hromad´ı zombie. Ve funkci pro takové vlákno je moˇzné jednoduˇse pouˇz´ıt toto: pthread detach(pthread self()); • Jin´ a moˇznost jak nastavit, ˇze se na vlákna nemus´ı ˇcekat, je zavolat funkci pthread attr setdetachstate s hodnotou PTHREAD CREATE DETACHED nad strukturou atribut˚ u a tu pak pouˇz´ıt ve volán´ıch pthread create. Pˇr´ıklad: pthreads/set-detachstate.c • Nastaven´ım NULL do argumentu val ptr systému sdˇelujeme, ˇze nás návratov´ a hodnota ukonˇceného vlákna nezaj´ımá. ˇ • Cekat na ukonˇcen´ı vl´ akna m˚ uˇze libovolné jiné vlákno, nejen to, které ho spustilo.

216

• Doporuˇcuji vˇzdy kontrolovat návratovou hodnotu pthread join, t´ım si budete jisti, ˇze ˇcek´ ate spr´ avnˇe, pˇri pouˇzit´ı ˇspatného ID vlákna funkce hned vrát´ı, coˇz v´ aˇs program nutnˇe nemus´ı negativnˇe ovlivnit co se t´ yká funkˇcnosti, ale m˚ uˇzete pak narazit na limit poˇctu vláken nebo vypl´ ytvat pamˇet’. • Na rozd´ıl od proces˚ u nelze ˇ cekat na ukonˇ cen´ı kter´ ehokoli vl´ akna. Je to z toho d˚ uvodu, ˇze vl´ akna nemaj´ı vztah rodiˇc–potomek, a proto to nebylo povaˇzov´ ano za potˇrebné. Pro zaj´ımavost, Solaris vlákna toto umoˇzn´ı (jako ID vl´ akna ve funkci thr join se pouˇzije 0). Pokud byste tuto funkˇcnost potˇrebovali s POSIXov´ ymi vlákny, je jednoduché nastavit vlákna jako detached, pouˇz´ıt podm´ınkové promˇenné, a pˇredávat potˇrebné informace pˇres glob´ aln´ı promˇennou pod ochranou zámku, kter´ y je s podm´ınkovou promˇennou sv´ az´ an. V´ıce viz strana 236. • Pˇr´ıklady: pthreads/pthread-join.c , pthreads/pthread-detach-join.c

Inicializace int pthread once(pthread once t *once control, void (*init routine )(void)); • V parametru once control se pˇredává ukazatel na staticky inicializovanou promˇennou pthread once t once control = PTHREAD ONCE INIT; • Prvn´ı vl´ akno, které zavolá pthread once(), provede inicializaˇcn´ı funkci init routine(). Ostatn´ı vlákna uˇz tuto funkci neprov´ adˇej´ı, nav´ıc, pokud inicializaˇcn´ı funkce jeˇstˇe neskonˇcila, zablokuj´ı se a ˇcekaj´ı na jej´ı dokonˇcen´ı. • Lze pouˇz´ıt napˇr. na dynamickou inicializaci globáln´ıch dat v knihovn´ ach, jejichˇz kód m˚ uˇze zavolat v´ıce vláken souˇcasnˇe, ale je tˇreba zajistit, ˇze inicializace probˇehne jen jednou.

• V programu samotném tuto funkci asi potˇrebovat nebudete. M´ısto pouˇzit´ı pthread once staˇc´ı danou inicializaˇcn´ı funkci zavolat pˇred t´ım, neˇz vytvoˇr´ıte vl´ akna... • Nen´ı definov´ ano, co se m´ a st´ at, pokud je once control automatická promˇenn´ a nebo nem´ a poˇzadovanou hodnotu.

217

Zruˇ sen´ı vl´ akna int pthread cancel(pthread t thread ); • poˇz´ ad´ a o zruˇsen´ı vl´ akna thread. Závis´ı na nastaven´ı int pthread setcancelstate(int state, int *old ); • nastav´ı nov´ y stav a vr´ at´ı star´ y: – PTHREAD CANCEL ENABLE . . . povoleno zruˇsit – PTHREAD CANCEL DISABLE . . . nelze zruˇsit, ˇzádost bude ˇcekat na povolen´ı int pthread setcanceltype(int type, int *old ); • PTHREAD CANCEL ASYNCHRONOUS . . . okamˇzité zruˇsen´ı • PTHREAD CANCEL DEFERRED . . . ˇzádost ˇceká na vstup do urˇcit´ ych funkc´ı (napˇr. open(), read(), wait()), nebo na volán´ı void pthread testcancel(void);

• Vl´ akna je moˇzné zvenku ,,násilnˇe” ruˇsit (obdoba ukonˇcen´ı procesu pomoc´ı sign´ alu) bud’ okamˇzitˇe, nebo jen v urˇcit´ ych volán´ıch (tzv. cancellation points). To znamen´ a, ˇze v takovém pˇr´ıpadˇe je moˇzné vlákno zruˇsit v ˇcase, kdy je vl´ akno vykon´ av´ a danou funkci. Pokud vlákno zrovna takovou funkci nevykon´ av´ a, informace o zruˇsen´ı se “doruˇc´ı” bˇehem vykonán´ı prvn´ı takové funkce od té doby. • Funkce pthread_cancel se podobá zruˇsen´ı procesu signálem poslan´ ym vol´ an´ım kill. • Pˇri zruˇsen´ı vl´ akna se zavolaj´ı u ´klidové handlery, viz strana 228. Pokud se rozhodnete ruˇsen´ı vl´ aken pouˇz´ıvat, bud’te velmi opatrn´ı. Napˇr´ıklad, pokud budete ruˇsit vl´ akno, které má zamknut´ y mutex, mus´ıte mutex odemknout v u ´klidov´ ych handlerech. • Funkce pthread_setcancelstate a pthread_setcanceltype jsou obdobou zak´ az´ an´ı a povolen´ı zruˇsen´ı procesu signálem pomoc´ı manipulace s maskou blokovan´ ych sign´ al˚ u (sigprocmask). • Pˇr´ıklad: pthreads/pthread-cancel.c • Pˇri ruˇsen´ı vl´ akna m˚ uˇze nastat mnoho moˇznost´ı. Solaris má tˇreba samostatnou manu´ alnovou str´ anku cancellation(5), která se tomu vˇenuje. FreeBSD definuje cancellation points v manuálové stránce pthread setcanceltype(3).

218

Pˇ r´ıklad: vl´ akna pthread_t id_a, id_b; void *res_a, *res_b; pthread_create(&id_a, NULL, do_a, "a"); pthread_create(&id_b, NULL, do_b, "b");

void *do_a(void *arg) { ... return arg; }

void *do_b(void *arg) { ... return arg; }

pthread_join(id_a, &res_a); pthread_join(id_b, &res_b);

• Toto je trivi´ aln´ı pˇr´ıklad, kdy proces (hlavn´ı vlákno) vytvoˇr´ı dvˇe dalˇs´ı vlákna a poˇck´ a na jejich ukonˇcen´ı.

219

Glob´ aln´ı promˇ enn´ e pro vl´ akno int pthread key create(pthread key t *key, void (*destructor )(void *)); • vytvoˇr´ı kl´ıˇc, kter´ y lze asociovat s hodnotou typu (void *). Funkce destructor() se volaj´ı opakovanˇe pro vˇsechny kl´ıˇce, jejichˇz hodnota nen´ı NULL, pˇri ukonˇcen´ı vlákna. int pthread key delete(pthread key t key ); • zruˇs´ı kl´ıˇc, nemˇen´ı asociovaná data. int pthread setspecific(pthread key t key, const void *value ); • pˇriˇrad´ı ukazatel value ke kl´ıˇci key. void *pthread getspecific(pthread key t key ); • vr´ at´ı hodnotu ukazatele pˇr´ısluˇsného ke kl´ıˇci key.

• Bˇeˇzné glob´ aln´ı promˇenné (a také dynamicky alokovaná data) jsou spoleˇcné pro vˇsechna vl´ akna. Kl´ıˇcované hodnoty pˇredstavuj´ı zp˚ usob, jak vytvoˇrit glob´ aln´ı promˇenné v r´ amci vl´ aken. Uvˇedomte si rozd´ıl proti lokáln´ı promˇenné definované ve vl´ aknové funkci - taková promˇenná nen´ı vidˇet v dalˇs´ıch volan´ ych funkc´ıch ve stejném vláknˇe. Vyuˇzitelnost soukrom´ ych atribut˚ u vláken se m˚ uˇze zd´ at mal´ a, ale obˇcas se to velmi dobˇre hod´ı. Já to jednou pouˇzil v existuj´ıc´ım k´ odu, kde jsem potˇreboval nahradit práci s globáln´ım spojov´ ym seznamem na lok´ aln´ı seznamy specifické pro kaˇzdé vlákno. Nejjednoduˇsˇs´ı, tj. nejménˇe zmˇen v existuj´ıc´ım kódu bylo pˇrevést práci s globáln´ı promˇennou na pr´ aci se soukrom´ ym atributem vlákna. • Pˇri vytvoˇren´ı kl´ıˇce je s n´ım asociována hodnota NULL. Ukazatel na destruktor funkci nen´ı povinn´ y, pokud nen´ı potˇreba, pouˇzijte NULL. • Pˇri ukonˇcen´ı nebo zruˇsen´ı vlákna se volaj´ı destruktory (v nespecifikovaném poˇrad´ı) pro vˇsechny kl´ıˇce s hodnotou r˚ uznou od NULL. Aktuáln´ı hodnota je destruktoru pˇred´ ana v parametru. Jestliˇze po skonˇcen´ı vˇsech destruktor˚ u zb´ yvaj´ı kl´ıˇce s hodnotou r˚ uznou od NULL, znovu se volaj´ı destruktory. Implementace m˚ uˇze (ale nemus´ı) zastavit volán´ı destruktor˚ u po PTHREAD DESTRUCTOR ITERATIONS iterac´ıch. Destruktor by tedy mˇel nastavit hodnotu na NULL, jinak hroz´ı nekoneˇcn´ y cyklus. • Destruktor si mus´ı s´ am zjistit kl´ıˇc poloˇzky, ke které patˇr´ı, a zruˇsit hodnotu vol´ an´ım pthread setspecific(key, NULL). • SUSv3 tento nesmysln´ y poˇzadavek odstraˇ nuje, protoˇze definuje, ˇze pˇred vstupem do destruktoru je hodnota automaticky nastavená na NULL; destruktor se n´ aslednˇe vyvol´ a s pˇredchoz´ı hodnotou kl´ıˇce. 220

´ Uklid pˇ ri ukonˇ cen´ı/zruˇ sen´ı vl´ akna • vl´ akno m´ a z´ asobn´ık u ´klidov´ ych handler˚ u, které se volaj´ı pˇri ukonˇcen´ı nebo zruˇsen´ı vlákna funkcemi pthread exit a pthread cancel (ale ne pˇri return). Handlery se spouˇst´ı v opaˇcném poˇrad´ı neˇz byly vkládány do zásobn´ıku. • po proveden´ı handler˚ u se volaj´ı destruktory privátn´ıch kl´ıˇcovan´ ych dat vl´ akna (poˇrad´ı nen´ı specifikované) void pthread cleanup push(void (*routine )(void *), void *arg ); • vloˇz´ı handler do z´ asobn´ıku. void pthread cleanup pop(int execute ); • vyjme naposledy vloˇzen´ y handler ze zásobn´ıku. Provede ho, pokud je execute nenulové.

• Handlery se volaj´ı jako routine(arg). • Tyto handlery se daj´ı pouˇz´ıvat napˇr. na u ´klid lokáln´ıch dat funkc´ı (obdoba vol´ an´ı destruktor˚ u pro automatické promˇenné v C++).

221

fork() a vl´ akna (POSIX) • je nutné definovat sémantiku volán´ı fork v aplikac´ıch pouˇz´ıvaj´ıc´ıch vl´ akna. Norma definuje, ˇze: – nov´ y proces obsahuje pˇresnou kopii volaj´ıc´ıho vlákna, vˇcetnˇe pˇr´ıpadn´ ych stav˚ u mutex˚ u a jin´ ych zdroj˚ u – ostatn´ı vl´ akna v synovském procesu neexistuj´ı – pokud takov´ a vl´ akna mˇela naalokovanou pamˇet’, z˚ ustane ’ tato pamˇet naalokovaná (= ztracená) – obdobnˇe to plat´ı pro zamˇcen´ y mutex jiˇz neexistuj´ıc´ıho vl´ akna • vytvoˇren´ı nového procesu z multivláknové aplikace má smysl pro n´ asledné vol´ an´ı exec (tj. vˇcetnˇe volán´ı popen, system apod.)

• Pokud mˇelo jiˇz neexistuj´ıc´ı vlákno zamˇcen´ y mutex, tak je pˇr´ıstup k pˇr´ısluˇsn´ ym sd´ılen´ ym dat˚ um ztracen, protoˇze zamˇcen´ y mutex m˚ uˇze odemknout pouze to vl´ akno, které ho zamknulo. Zde ale trochu pˇredb´ıhám, mutexy jsou pˇredstavené aˇz na stranˇe 233. • Ostatn´ı vl´ akna v novém procesu pˇrestanou existovat, nevolaj´ı se ˇzádné rutiny ych jako pˇri vol´ an´ı pthread exit, pthread cancel nebo destruktory kl´ıˇcovan´ dat. • Pozor na to, ˇze chov´ an´ı fork také závis´ı na pouˇzité knihovnˇe a verzi systému, napˇr´ıklad na Solarisu pˇred verz´ı 10 znamenalo fork v knihovnˇe libthread (jin´ a knihovna neˇz libpthread) to samé co forkall. • Pˇr´ıklady: pthreads/fork.c , pthreads/fork-not-in-main.c , pthreads/forkall.c • Pomoc´ı funkce pthread atfork je moˇzné nastavit handlery které se automaticky vykonaj´ı pˇred pouˇzit´ım fork v rodiˇci a po návratu z fork v rodiˇci a synovském procesu. Toto volán´ı se velmi hod´ı pro vˇsechny multithreadové programy které volaj´ı fork a nepouˇz´ıvaj´ı ho pouze jako jednoduch´ y wrapper pro exec. Po fork se totiˇz v synovském procesu nacházej´ı vˇsechny promˇenné ve stejném stavu jako byly v rodiˇci ve chv´ıli kdy se zavolal fork a tedy pokud mˇelo nˇejaké jiné vl´ akno (neˇz které zavolalo fork) napˇr. zamˇcen´ y mutex (zamyk´ an´ı pomoc´ı mutex˚ u viz strana 233) tak bude tento mutex zamˇcen´ yiv synovském procesu. Pokud se pak vlákno ze synovského procesu tento mutex pokus´ı zamknout, dojde k deadlocku. Pokud se v pre-fork handleru provede zamˇcen´ı vˇsech mutex˚ u a v obou (rodiˇc i syn) post-fork handler˚ u odemˇcen´ı vˇsech mutex˚ u, tato situace nenastane. Tento mechanismus funguje d´ıky tomu, 222

ˇze pre-fork handler se zavol´ a ve vláknu, které zavolalo fork, jeˇstˇe pˇredt´ım neˇz se provede samotn´ y fork syscall; ostatn´ı vlákna mezit´ım dál bˇeˇz´ı a mohou tedy uvolnit mutexy (jednoduˇse tak ˇze kaˇzdé vlákno v rozumnˇe napsaném programu ˇcasem opust´ı kritickou sekci), na které se ˇceká v handleru. Toto samozˇrejmˇe pˇredpokl´ ad´ a, ˇze zamykán´ı a odemykán´ı v handlerech dodrˇzuje zamykac´ı pravidla (”protokol”) stanoven´ y pro cel´ y program a nedojde tedy k deadlocku. pthreads/atfork.c V´ıce napˇr. v [Butenhof].

Sign´ aly a vl´ akna • sign´ aly mohou b´ yt generovány pro proces (volán´ım kill), nebo pro vl´ akno (chybové události, volán´ı pthread kill). • nastaven´ı obsluhy sign´ al˚ u je stejné pro vˇsechna vlákna procesu, ale masku blokovan´ ych signál˚ u má kaˇzdé vlákno vlastn´ı, nastavuje se funkc´ı int pthread sigmask(int how, const sigset t *set, sigset t *oset ); • sign´ al urˇcen´ y pro proces oˇsetˇr´ı vˇzdy právˇe jedno vlákno, které nem´ a tento sign´ al zablokovan´ y. • lze vyhradit jedno vl´ akno pro synchronn´ı pˇr´ıjem signál˚ u pomoc´ı vol´ an´ı sigwait. Ve vˇsech vláknech se signály zablokuj´ı.

• Jestliˇze je pro sign´ al nastaveno ukonˇcen´ı procesu, skonˇc´ı cel´ y proces, nejen jedno vl´ akno. • Vytvoˇrené vl´ akno dˇed´ı nastaven´ı signálové masky od vlákna, které ho vytvoˇrilo • Analogicky k pouˇzit´ı sigwait s procesy (strana 165) – zablokujte pˇr´ısluˇsné sign´ aly ve vˇsech vl´ aknech, vˇcetnˇe vlákna, ve kterém chcete zpracovávávat sign´ aly pomoc´ı sigwait. Tento zp˚ usob zpracov´ an´ı sign´ al˚ u b´ yv´ aˇ casto jedin´ y opravdu doporuˇ covan´ y pro vl´ akna, a nav´ıc je i nejsnáze implementovateln´ y. Jak vypl´ yv´ a z pˇredchoz´ı poznámky, staˇc´ı zamaskovat signály pouze jednou, a to v hlavn´ım vláknˇe, protoˇze maska se pak podˇed´ı pˇri kaˇzdém vol´ an´ı pthread create. • V prostˇred´ı vl´ aken nepouˇz´ıvejte sigprocmask (strana 163), protoˇze chován´ı tohoto vol´ an´ı nen´ı v takovém prostˇred´ı normou specifikováno. M˚ uˇze to fungovat, a také nemus´ı. • Pˇr´ıklad: pthreads/sigwait.c . 223

• Pozor na to, ˇze byste nemˇeli tento zp˚ usob obsluhy signál˚ u pouˇz´ıvat pro sign´ aly synchronn´ı jako jsou SIGSEGV, SIGILL, apod. Tyto signály jsou generované pˇr´ımo pro vl´ akno, takˇze pokud je zablokujete, vlákno urˇcené pro synchronn´ı pˇr´ıjem sign´ al˚ u je nemus´ı “vidˇet”, jedinˇe pokud by ten signál zp˚ usobilo samo, samozˇrejmˇe. Dalˇs´ı vˇec ale je, ˇze specifikac´ı nen´ı definováno, zda blokov´ an´ı takov´ ych sign´ al˚ u tyto signály skuteˇcnˇe zablokuje, jak jiˇz bylo zm´ınˇeno na stranˇe 156. Nˇekteré systémy tyto signály normálnˇe doruˇc´ı, ˇc´ımˇz proces ukonˇc´ı, viz pˇresné znˇen´ı: If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function. Pˇr´ıklad: pthreads/sigwait-with-sync-signals.c . Tento pˇr´ıklad ukazuje, ˇze na Solarisu 10, Solarisu 11, FreeBSD 7.2 a Linux distribuci, která se hlás´ı jako “Gentoo Base System release 1.12.13”, je signál SIGSEGV doruˇcen a proces zabit bez ohledu na to, zda je maskován. Naˇsel jsem ale i systém, kter´ y po zamaskov´ an´ı sign´ al nedoruˇc´ı – FreeBSD 6.0. Synchronn´ı signály by ale mˇelo b´ yt vˇzdy moˇzné zachytit (pˇred zavolán´ım exit), viz strana 156, kde je i pˇr´ıklad.

Synchronizace vl´ aken obecnˇ e • vˇetˇsina program˚ u pouˇz´ıvaj´ıc´ıch vlákna mezi nimi sd´ıl´ı data • nebo vyˇzaduje, aby r˚ uzné akce byly provádˇeny v jistém poˇrad´ı • . . . toto vˇse potˇrebuje synchronizovat aktivitu bˇeˇz´ıc´ıch vláken • jak bylo zm´ınˇeno u implementace vláken, u proces˚ u je pro sd´ılen´ı dat nutné vynaloˇzit jisté u ´sil´ı, u vláken naopak mus´ıme investovat do toho, abychom pˇrirozené sd´ılen´ı dat uhl´ıdali • my se vzhledem k vl´ akn˚ um budeme zab´ yvat: – mutexy – podm´ınkov´ ymi promˇenn´ ymi – read-write z´ amky

• pro pˇripomenut´ı, synchronizac´ı proces˚ u jsme se jiˇz zab´ yvali na stranách 167 aˇz 184. • pomoc´ı mutex˚ u a podm´ınkov´ ych promˇenn´ ych je moˇzné postavit jak´ ykoli jin´ y synchronizaˇcn´ı model. 224

• na tom jak´ ym zp˚ usobem budou fungovat synchronizaˇcn´ı primitiva se velkou ˇc´ ast´ı pod´ıl´ı scheduler, kter´ y napˇr. rozhoduje které z vláken ˇcekaj´ıc´ıch na odemˇcen´ı bude po odemˇcen´ı probuzeno. S t´ım souvis´ı klasické problémy, napˇr. thundering horde (na odemˇcen´ı ˇceká velké mnoˇzstv´ı vláken) nebo priority inversion (vl´ akno, které drˇz´ı zámek, má menˇs´ı prioritu neˇz vlákno, které ˇcek´ a na tento z´ amek).

Synchronizace vl´ aken: mutexy (1) • nejjednoduˇsˇs´ı zp˚ usob zajiˇstˇen´ı synchronizovaného pˇr´ıstupu ke sd´ılen´ ym dat˚ um mezi vlákny je pouˇzit´ım mutexu • inicializace staticky definovaného mutexu: pthread mutex t mutex = PTHREAD MUTEX INITIALIZER; • inicializace dynamicky alokovaného mutexu mx s atributy attr (nastavuj´ı se pomoc´ı pthread mutexattr ...; a je-li m´ısto attr pouˇzit NULL, vezmou se defaultn´ı atributy) int pthread mutex init(pthread mutex t *mx, const pthread mutexattr t *attr ); • po skonˇcen´ı pouˇz´ıv´ an´ı mutexu je moˇzné ho zruˇsit: int pthread mutex destroy(pthread mutex t *mx );

• Mutex = mutual exclusion (vzájemné vylouˇcen´ı) • Je to speci´ aln´ı forma Dijkstrov´ ych semafor˚ u – rozd´ıl mezi mutexy a binárn´ımi semafory je ten, ˇze mutex m´ a majitele a zamˇ cen´ y mutex mus´ı odemknout pouze to vl´ akno, kter´ e ho zamknulo. To u semafor˚ u neplat´ı. Pozor na to, ˇze abyste zjistili, ˇze napˇr´ıklad zkouˇs´ıte odemknout mutex, kter´ y dané vl´ akno nezamknulo, je nutné jednak testovat návratovou hodnotu volán´ı pthread mutex lock, a také je nutné ovˇeˇrit, ˇze máte nastavenou kontrolu zamyk´ an´ı; viz d´ ale. • Mutexy jsou urˇcené pouze ke krátkodobému drˇzen´ı a mˇely by fungovat rychle. Slouˇz´ı pro implementaci kritick´ ych sekc´ı (definice je na stranˇe 169), podobnˇe jako lock-soubory nebo semafory (pouˇzité jako zámky). • Kontrola zamyk´ an´ı u mutex˚ u – defaultnˇe je typ mutexu PTHREAD MUTEX DEFAULT. V tomto nastaven´ı nejsou normou definovány v´ ysledky zamknut´ı jiˇz zamknutého mutexu, odemknut´ı mutexu zamknutého jin´ ym vláknem ani odemknut´ı odemknutého mutexu. Implementace si namapuj´ı toto makro na normou definované PTHREAD MUTEX NORMAL nebo PTHREAD MUTEX ERRORCHECK. M˚ uˇze se v´ am proto v z´ avislosti na konkrétn´ı implementaci stát, ˇze pokud 225

v defaultn´ı konfiguraci zamknete jiˇz jednou zamknut´ y mutex, nastane deadlock (normal), a nebo také ne (errorcheck). V tom druhém pˇr´ıpadˇe dostanete n´ avratovou hodnotu o chybˇe a pokud ji netestujete, budete se mylnˇe domn´ıvat, ˇze jste mutex zamknuli. U normal nen´ı v´ ysledek zbyl´ ych dvou situac´ı definov´ an, u errorcheck se vám vrát´ı chyba. “Nedefinováno” u normal znamen´ a, ˇze vl´ akno odemykaj´ıc´ı mutex, kter´ y nezamknulo, ho klidnˇe m˚ uˇze odemknout, nebo také ne – vˇse závis´ı na konkrétn´ı implementaci. “Nedefinov´ ano” ale také znamená, ˇze skuteˇcn´ y v´ ysledek takov´ ychto situac´ı by v´ as nemˇel zaj´ımat, protoˇze byste se jim vˇzdy mˇeli vyhnout. V´ıce informac´ı viz norma nebo manuálová stránka k pthread mutexattr settype. Mnˇe osobnˇe pˇrijde testov´ an´ı mutexov´ ych funkc´ı jako nadbyteˇcné a trochu znepˇrehledˇ nuj´ıc´ı k´ od, ale m˚ uˇze b´ yt dobr´ y nápad je pouˇz´ıvat pˇri v´ yvoji kódu, a pˇred odevzd´ an´ım fin´ aln´ı verze pak testy odstranit. Solaris a Linux defaultnˇe pouˇz´ıvaj´ı nastaven´ı normal, FreeBSD pouˇz´ıvá errorcheck. Pˇr´ıklad: mutexes/not-my-lock.c . • dalˇs´ı typ je PTHREAD MUTEX RECURSIVE které drˇz´ı poˇcet zamˇcen´ı dan´ ym threadem. Ostatn´ı thready dostanou pˇr´ıstup jedinˇe tehdy kdyˇz poˇcet dosáhne 0. Tento typ mutexu nelze sd´ılet mezi procesy. • K ˇcemu jsou dobré rekurzivn´ı mutexy ? Napˇr. máme-li knihovn´ı funkci A:foo(), kter´ a z´ısk´ a mutex a zavol´ a B:bar() která ale m˚ uˇze zavolat A:bar(), která se pokus´ı z´ıskat ten sam´ y mutex. Bez rekurzivn´ıch zámk˚ u by doˇslo k deadlocku. S rekurzivn´ımi mutexy je to ok pokud tyto volán´ı provád´ı ten sam´ y thread (jin´ y thread by se zablokoval), pokud si tedy A:foo() a A:bar() jsou vˇedomy, ˇze ten sam´ y thread uˇz m˚ uˇze b´ yt v kritické sekci. • typ mutexu se nastavuje pomoc´ı funkce pthread mutex setattrtype. • Chov´ an´ı v jednotliv´ ych pˇr´ıpadech podle typu mutexu shrnuje tabulka: detekuje deadlock v´ıcen´ asobné zamyk´ an´ı odemˇcen´ı jin´ ym vl´ aknem odemyk´ an´ı odemˇceného lze sd´ılet mezi procesy

NORMAL N deadlock unedfined undefined Y

ERRORCHECK Y error error error Y

RECURSIVE N/A success error error N

• Inicializace statického mutexu pomoc´ı zm´ınˇeného makra nastav´ı pro mutex jeho defaultn´ı atributy. Je moˇzné pouˇz´ıt inicializaˇcn´ı funkci i pro staticky alokované mutexy. Pokud je mutex alokován dynamicky, je vˇzdy nutné pouˇz´ıt pthread mutex init funkci, at’ jiˇz budeme pouˇz´ıvat defaultn´ı atributy nebo ne. • Dynamické mutexy m˚ uˇzeme potˇrebovat napˇr´ıklad v situaci, kdy dynamicky alokujeme datovou strukturu, jej´ıˇz souˇcást´ı je i mutex, kter´ y sd´ılená data struktury chr´ an´ı. I zde, pˇred zavolán´ım funkce free na datovou strukturu, je potˇreba pouˇz´ıt vol´ an´ı pro zruˇsen´ı mutexu, protoˇze mutex sám m˚ uˇze m´ıt napˇr´ıklad alokovanou nˇejakou pamˇet’. V´ ysledek zruˇsen´ı zamknutého mutexu nen´ı normou definov´ an. • Kop´ırovat mutexy nen´ı normou definováno – v´ ysledek takové operace závis´ı na implementaci. Je moˇzné samozˇrejmˇe zkop´ırovat ukazatel na mutex a s t´ımto ukazatelem pak d´ ale pracovat. • Zruˇsen´ı mutexu znamen´ a jeho deinicializaci. 226

Mutexy (2) • pro zamˇcen´ı a odemˇcen´ı mutexu pouˇzijeme volán´ı: int pthread mutex lock(pthread mutex t *mx ); a int pthread mutex unlock(pthread mutex t *mx ); • pokud je mutex jiˇz zamˇcen´ y, pokus o zamknut´ı vy´ ust´ı v zablokov´ an´ı vl´ akna. Je moˇzné pouˇz´ıt i volán´ı: int pthread mutex trylock(pthread mutex t *mx ); . . . které se pokus´ı zamknout mutex, a pokud to nelze provést, skonˇc´ı s chybou

• zamknout mutex, pokud ho dané vlákno jiˇz zamˇcené má, nen´ı korektn´ı. Nˇekdy m˚ uˇze doj´ıt i k self dead-locku, viz pˇredchoz´ı strana. Pokud potˇrebujete odemknout mutex, kter´ y zamknulo jiné vlákno, pouˇzijte m´ısto toho binárn´ı semafor; opˇet viz pˇredchoz´ı strana. • pˇri vytv´ aˇren´ı aplikace, kde je efektivita kl´ıˇcov´ ym faktorem, je nutné rozmyslet, jak, kde a kolik mutex˚ u pouˇz´ıvat. Z knihovny, která nebyla napsaná pro pouˇzit´ı v aplikac´ıch pouˇz´ıvaj´ıc´ı vlákna, je moˇzné udˇelat thread-safe (viz také strana 247) knihovnu tak, ˇze pˇred zavolán´ım jakékoli funkce knihovny zamknu jeden, tzv. “giant” mutex a po skonˇcen´ı funkce ho odemknu. Mám tedy pouze jeden mutex, ale vlákna pouˇz´ıvaj´ıc´ı tuto knihovnu ˇcasto sp´ı pˇri ˇcek´ an´ı na pˇr´ıstup do knihovny. Na druhou stranu, pokud zamykám pˇr´ıstup ke konkrétn´ım, mal´ ym sekc´ım, mohu potˇrebovat mnoho mutex˚ u a znaˇcné mnoˇzstv´ı ˇcasu tak mohu str´ avit ve funkc´ıch, které mutexy implementuj´ı. Je proto vhodné podle situace zvolit rozumn´ y kompromis. Také nezapomeˇ nte, ˇze je moˇzné explicitnˇe nastavit, zda chcete error checking u mutex˚ u nebo ne. M˚ uˇze b´ yt dobré ˇreˇsen´ı kontrolu zamykán´ı/odemykán´ı vypnout tehdy, kdyˇz uˇz m´ ate vˇse otestované a vˇeˇr´ıte, ˇze error checking kód dále nepotˇrebujete. • pˇr´ıklady: mutexes/race.c a mutexes/race-fixed.c • mutexy je moˇzné nastavit i pro fungovan´ı mezi vlákny r˚ uzn´ ych proces˚ u. Funguje to tak, ˇze funkce implementuj´ıc´ı mutexy vyuˇzij´ı sd´ılenou pamˇet’, jej´ıˇz odkaz se nastav´ı jako jeden z atribut˚ u mutexu. V´ıce viz manuálová stránka pro pthread mutexattr setpshared.

227

Podm´ınkov´ e promˇ enn´ e (1) • mutexy slouˇz´ı pro synchronizaci pˇr´ıstupu ke sd´ılen´ ym dat˚ um • podm´ınkové promˇenné pak k pˇredán´ı informac´ı o tˇechto sd´ılen´ ych datech – napˇr´ıklad ˇze se hodnota dat zmˇenila • . . . a umoˇzn´ı tak vl´ akna podle potˇreby uspávat a probouzet • z toho plyne, ˇze kaˇ zd´ a podm´ınkov´ a promˇ enn´ a je vˇ zdy asociov´ ana s pr´ avˇ e jedn´ım mutexem • jeden mutex ale m˚ uˇze b´ yt asociován s v´ıce podm´ınkov´ ymi promˇenn´ ymi • spoleˇcnˇe pomoc´ı mutex˚ u a podm´ınkov´ ych promˇenn´ ych je moˇzné vytv´ aˇret dalˇs´ı synchronizaˇcn´ı primitiva – semafory, bariéry, . . .

• jin´ ymi slovy – podm´ınkové promˇenné se pouˇz´ıvaj´ı v situaci, kdy vlákno potˇrebuje otestovat stav sd´ılen´ ych dat (napˇr. poˇcet zpráv ve frontˇe), a dobrovolnˇe se uspat, kdyˇz hledaného stavu nebylo dosaˇzeno. Sp´ıc´ı vlákno je pak probuzeno jin´ ym vl´ aknem, které zmˇenilo stav dat tak, ˇze nastala situace, na kterou prvn´ı vl´ akno ˇcek´ a (tˇreba vloˇzen´ım prvku do fronty). Druhé vlákno vzbud´ı prvn´ı vl´ akno zavol´ an´ım k tomu urˇcené funkce. Pokud ˇzádné vlákno v dané chv´ıli nesp´ı, probouzec´ı funkce nemá ˇzádn´ y efekt – nic se nikde neuloˇz´ı, prostˇe jako by se to nikdy nestalo. • nen´ı to tak, ˇze pˇri deklaraci podm´ınkové promˇenné, coˇz je pro programátora zcela transparentn´ı typ, s n´ı asociujete podm´ınku napˇr. “n je vˇetˇs´ı neˇz 7 ”. Podm´ınkovou promˇennou totiˇz m˚ uˇzete pˇrirovnat k praporu nˇejaké barvy, a pokud jej zvednete, znamen´ a to, ˇze ta vlákna, která ˇcekaj´ı aˇz touto vlajkou nˇekdo zam´ av´ a nad hlavou, jsou o této situaci informována (= vzbuzena) a mohou se podle toho zaˇr´ıdit. Nˇekterá vlákna tak mohou ˇcekat na to, aˇz n bude vˇetˇs´ı neˇz 7, jin´ a mohou ˇcekat pouze na to, aˇz se n jakkoli zmˇen´ı. Je pouze na program´ atorovi, zda pro kaˇzdou konkrétn´ı situaci pouˇzije jednu podm´ınkovou promˇennou, nebo jednu pro vˇsechny situace dohromady. Pro druhou situaci plat´ı, ˇze vl´ akna ˇcekaj´ıc´ı na n == 7 pak mus´ı vˇzdy n otestovat, protoˇze v´ı, ˇze je vzbuzeno pˇri kazdé zmˇenˇe ˇc´ıtaˇce n. Pokud nen´ı ˇc´ıtaˇc roven sedmi, znovu se dobrovolnˇe usp´ı. Jak je vˇsak uvedeno dále, test je nutn´ e po probuzen´ı prov´ est vˇ zdy, i kdyˇz pro nˇej pouˇz´ıváte samostatnou podm´ınkovou promˇennou – m˚ uˇze se st´ at, ˇze systém z r˚ uzn´ ych implementaˇcn´ıch d˚ uvod˚ u vzbud´ı vl´ akno uspané nad podm´ınkovou promˇennou, aniˇz by to zp˚ usobilo jiné vl´ akno a tedy aniˇz by stav na kter´ y vlákno ˇceká opravdu nastal.

228

Podm´ınkov´ e promˇ enn´ e (2) int pthread cond init(pthread cond t *cond, const pthread condattr t *attr ); • Inicializuje podm´ınkovou promˇennou cond s atributy attr (nastavuj´ı je funkce pthread condattr ...()), NULL = default. int pthread cond destroy(pthread cond t *cond ); • zruˇs´ı podm´ınkovou promˇennou. int pthread cond wait(pthread cond t *cond, pthread mutex t *mutex ); • ˇcek´ a na podm´ınkové promˇenné dokud jiné vlákno nezavolá pthread cond signal() nebo pthread cond broadcast().

• je nutné, aby po té, co vl´ akno zamkne mutex a dˇr´ıve, neˇz vlákno zavolá pthread cond wait, otestovat podm´ınku. Pokud tuhle operaci vlákno neprovede, mohlo by se uspat na neurˇcitou dobu, protoˇze hláˇska o splnˇen´ı podm´ınky od jiného vl´ akna by proˇsla “bez povˇsimnut´ı”. Jinak ˇreˇceno, nesm´ım se uspat pˇri ˇcek´ an´ı na situaci, která uˇz mezit´ım nastala. Nefunguje to jako sign´ aly, které pro v´ as systém drˇz´ı, pokud je máte napˇr´ıklad zablokované. Co je d˚ uleˇzité je to, ˇze ten test provád´ıte pod ochranou mutexu, tedy si opravdu m˚ uˇzete b´ yt jist´ı dan´ ym stavem vˇec´ı pˇri zavolán´ı pthread cond wait. • to, ˇze podm´ınkové promˇenné opravdu funguj´ı je zp˚ usobeno t´ım, ˇze pˇri vstupu do kritické sekce vl´ akno zamkne mutex a funkce pthread cond wait pˇ red usp´ an´ım vl´ akna mutex odemkne. Pˇred návratem z této funkce se pak mutex opˇet zamkne. M˚ uˇze se tedy stát, ˇze vlákno je probuzeno z ˇcekán´ı nad podm´ınkovou promˇennou, ale nˇejak´ y ˇcas se pak jeˇstˇe usp´ı pˇri pokusu o zamknut´ı mutexu. Nehledejte v tom nic sloˇzitého, jde pouze o klasické vz´ ajemné vylouˇcen´ı proces˚ u nad kritickou sekc´ı.

229

Podm´ınkov´ e promˇ enn´ e (3) int pthread cond signal(pthread cond t *cond ); • probud´ı jeden proces ˇcekaj´ıc´ı na podm´ınkové promˇenné cond. int pthread cond broadcast(pthread cond t *cond ); • probud´ı vˇsechny procesy ˇcekaj´ıc´ı na podm´ınkové promˇenné cond. int pthread cond timedwait(pthread cond t *cond, pthread mutex t *mutex, const struct timespec *atime ); • ˇcek´ a na pthread cond signal() nebo pthread cond broadcast(), ale maximálnˇe do doby neˇz systémov´ y ˇcas dos´ ahne hodnoty dané atime.

• jak jiˇz bylo ˇreˇceno, jedna podm´ınková promˇenná m˚ uˇze b´ yt pouˇzita pro hláˇsen´ı nˇekolika rozd´ıln´ ych situac´ı najednou – napˇr´ıklad pˇri vloˇzen´ı prvku do fronty i pˇri jeho vyjmut´ı. Z toho d˚ uvodu je nutné po probuzen´ı otestovat podm´ınku, na kterou se ˇceká. Dalˇs´ı vˇec, která z toho vycház´ı je ta, ˇze v takovém pˇr´ıpadˇe mus´ıte pouˇz´ıt broadcast. Staˇc´ı si pˇredstavit následuj´ıc´ı situaci – ˇcek´ ate na podm´ınku “zmˇenil se stav fronty”, na které ˇcekaj´ı ˇctenáˇri i zapisovatelé (pˇredpokl´ adejme, ˇze jednu frontu pouˇz´ıvá v´ıce ˇctenáˇr˚ u i v´ıce zapisovatel˚ u). Pokud po vloˇzen´ı zprávy pouze vypust´ıte jednu signalizaci, tak se m˚ uˇze st´ at, ˇze tato signalizace probud´ı jiného zapisovatele, kter´ y ale samozˇrejmˇe ˇcek´ a na situaci, kdy ˇctenáˇr z fronty zprávu odebere. T´ım se stane, ˇze ve frontˇe z˚ ustane zpr´ ava, která m˚ uˇze b´ yt vytlaˇcena aˇz dalˇs´ı signalizac´ı. • vl´ akno m˚ uˇze b´ yt probuzeno jin´ ym vláknem i v pˇr´ıpadˇe, ˇze je podm´ınková promˇenn´ a sv´ az´ ana pouze s jednou konkrétn´ı událost´ı, která vˇsak po probuzen´ı vl´ akna jiˇz neplat´ı. Pˇredstavte si, ˇze tˇesnˇe po té, kdy jiné vlákno zahlás´ı splnˇen´ı podm´ınky, m˚ uˇze dalˇs´ı vlákno zamknout mutex a nˇejakou akc´ı, napˇr. vyjmut´ım prvku z fronty, zruˇsit platnost podm´ınky “ve frontˇe je zpráva”. To vl´ akno, které je probuzeno, tak najde frontu prázdnou. Dalˇs´ı d˚ uvod pro to, ˇze podm´ınkové promˇenné je nutné vˇ zdy testovat v cyklu. • v ˇr´ıdk´ ych pˇr´ıpadech je moˇzné, ˇze se vlákno probud´ı a podm´ınka nen´ı platná i d´ıky konkrétn´ı implementaci. Z toho opˇet vypl´ yvá nutnost pouˇzit´ı cyklu. • v parametru abstime funkce pthread cond timedwait se pˇredává absolutn´ı ˇcas, tj. timeout vyprˇs´ı, kdyˇz systémov´ y ˇcas dosáhne hodnoty vˇetˇs´ı nebo rovné abstime. Pro absolutn´ı ˇcas bylo rozhodnuto proto, aby programátor nemusel

230

pˇri pˇr´ıpadn´ ych probuzen´ıch, kdy následnˇe zjist´ı, ˇze daná podm´ınka neplat´ı, pˇrepoˇc´ıt´ avat ˇcasov´ y rozd´ıl.

Pouˇ zit´ı podm´ınkov´ ych promˇ enn´ ych pthread cond t cond; pthread mutex t mutex; ... pthread mutex lock(&mutex); while (!podminka(data)) pthread cond wait(&cond, &mutex); process data(data, ...); pthread mutex unlock(&mutex); ... pthread mutex lock(&mutex); produce data(data, ...); pthread cond signal(&cond); pthread mutex unlock(&mutex);

• Prvn´ı kus k´ odu ˇcek´ a na zmˇenu podm´ınky. Pokud k n´ı dojde, data zmˇenila a tedy mohou b´ yt zpracov´ ana. Druh´ y kus kódu (spuˇstˇen´ y v jiném vláknˇe) data pˇripravuje ke zpracov´ an´ı. Jakmile jsou pˇripravena, zasignalizuje konzumentovi. • pro zopakov´ an´ı – ke kaˇzdé podm´ınkové promˇenné je potˇreba m´ıt jeˇstˇe mutex. • funkce pthread cond wait atomicky odemkne mutex a usp´ı vlákno. Kdyˇz je vl´ akno probuzeno, nejprve se znovu zamkne mutex (tj. toto zamknut´ı se provede v r´ amci pˇr´ısluˇsné implementace podm´ınkov´ ych promˇenn´ ych!) a teprve pak se vol´ an´ı pthread cond wait vrát´ı. • kdyˇz signalizujeme, ˇze se nˇeco zmˇenilo, neznamená to jeˇstˇe, ˇze po zmˇenˇe bude platit podm´ınka. Nav´ıc, jak bylo nˇekolikrát zd˚ uraznˇeno, pthread cond wait m˚ uˇze vr´ atit, i kdyˇz ˇz´ adné jiné vlákno nezavolalo pthread cond signal ani pthread cond broadcast. Dalˇs´ı d˚ uvod proˇc je potˇreba znovu otestovat podm´ınku a pˇr´ıpadnˇe obnovit ˇcekán´ı. • vˇsimnˇete si, ˇze odemknut´ı zámku následuje aˇz po signalizaci podm´ınky. Je velmi jednoduché naj´ıt situaci, kdy byste se dostali do problém˚ u, pokud byste signalizovali mimo kritickou sekci. Pˇredstavte si, ˇze dvˇe vlákna pˇridaj´ı prvek do fronty. Prvn´ı zasignalizuje a t´ım probud´ı ˇctenáˇre, kter´ y vyjme jeden prvek a zpracov´ av´ a ho. Bˇehem toho dojde k druhé signalizaci, která protoˇze je mimo kritickou sekci, nastane v dobˇe, kdy ˇctenáˇr jeˇstˇe zpracovává prvn´ı prvek a

231

tedy se vlastnˇe “ztrat´ı”. N´ aslednˇe se ˇctenáˇr usp´ı pthread cond wait, a druh´ y prvek tak ve frontˇe z˚ ustane, dokud jiné vlákno nevloˇz´ı prvek jin´ y (a ten bude ve frontˇe viset podobn´ ym zp˚ usobem). • pˇr´ıklad: cond-variables/queue-simulation.c

Read-write z´ amky (1) int pthread rwlock init(pthread rwlock t *l, const pthread rwlockattr t *attr ); • vytvoˇr´ı z´ amek s atributy podle attr (nastavuj´ı se funkcemi pthread rwlockattr ...(), NULL = default) int pthread rwlock destroy(pthread rwlock t *l ); • zruˇs´ı z´ amek int pthread rwlock rdlock(pthread rwlock t *l ); int pthread rwlock tryrdlock(pthread rwlock t *rwlock ); • zamkne z´ amek pro ˇcten´ı (v´ıce vláken m˚ uˇze drˇzet zámek pro ˇcten´ı), pokud m´ a nˇekdo zámek pro zápis, usp´ı volaj´ıc´ı vlákno (rdlock()) resp. vr´ at´ı chybu (tryrdlock()).

• nen´ı souˇc´ ast´ı POSIXov´ ych vláken z POSIX.1c, ale POSIX.1j rozˇs´ıˇren´ı, nazvané “advanced realtime extensions”. • najednou m˚ uˇze m´ıt z´ amek bud’ nˇekolik vláken zamˇceno pro ˇcten´ı nebo maxim´ alnˇe jedno vl´ akno zamˇceno pro zápis (a nikdo pro ˇcten´ı). • read-write z´ amky jsou semanticky podobné zamykán´ı soubor˚ u pomoc´ı funkce fcntl.

232

Read-write z´ amky (2) int pthread rwlock wrlock(pthread rwlock t *rwlock ); • zamkne z´ amek pro z´ apis, pokud má nˇekdo zámek pro ˇcten´ı nebo z´ apis, ˇcek´ a. int pthread rwlock trywrlock(pthread rwlock t *rwlock ); • jako pthread rwlock wrlock(), ale kdyˇz nem˚ uˇze zamknout, vr´ at´ı chybu. int pthread rwlock unlock(pthread rwlock t *rwlock ); • odemkne z´ amek

• zvl´ aˇstnost: pokud vl´ akno ˇcekaj´ıc´ı na zámek dostane signál, po návratu z handleru se vˇzdy pokraˇcuje v ˇcekán´ı, tj. nenastane chyba EINTR. Takto se chovaj´ı i mutexy a podm´ınkové promˇenné.

233

Atomick´ e aritmetick´ e operace • pro architektury, kde operace sˇc´ıtán´ı nen´ı atomická • atomic add(3c) od Solarisu 10, atomic(3) na OS X • v´ yraznˇe rychlejˇs´ı neˇz jiné mechanismy pro z´ıskán´ı exkluzivn´ıho pˇr´ıstupu • sada vol´ an´ı pro r˚ uzné celoˇc´ıselné typy, napˇr´ıklad na Solarisu: void atomic add int(volatile uint t *target, int delta); void atomic add 8(volatile uint8 t *target, int8 t delta); . . . a dalˇs´ı

• Pˇr´ıklad race/atomic-add.c demonstruje problém se soubˇehem pˇri sˇc´ıtán´ı a jeho moˇzn´ a ˇreˇsen´ı. Program spust´ı dvˇe vlákna, kaˇzdé vlákno pracuje se stejnou glob´ aln´ı promˇennou x, do které v cyklu postupnˇe pˇriˇcte ˇc´ısla od jedné do velikosti parametru arg, kter´ y program dostane na pˇr´ıkazové ˇrádce. Vl´ akna bˇeˇz´ı paralelnˇe, kaˇzdé z nich provád´ı toto: for (i = 1; i < arg; ++i) x = x + i; Poté se sˇc´ıt´ an´ı pro kontrolu provede v hlavn´ım vláknu, a dvojnásobek (mˇeli jsme dva thready) se porovn´ a s hodnotou globáln´ı promˇenné x. Pokud nejsou v´ ysledky stejné, doˇslo k soubˇehu (pˇreteˇcen´ı promˇenné m˚ uˇzeme v této situaci zcela ignorovat). V´ ysledky a ˇcasy bˇehu se markantnˇe liˇs´ı pro situace, kdy program pouˇzil obyˇcejné sˇc´ıt´ an´ı, funkci atomic add int() a zamykán´ı pomoc´ı mutex˚ u. Je vidˇet nˇekolikan´ asobn´ y rozd´ıl v dobˇe bˇehu mezi pouˇzit´ım atomic add a mutex˚ u, zejména na procesorech s hardwarov´ ymi thready (jako napˇr. UltraSPARC T1). • Atomické aritmetické rutiny lze d´ıky tomu, ˇze druh´ y argument je celé ˇc´ıslo, pouˇz´ıt i k atomickému odeˇc´ıtán´ı. Podobnˇe existuj´ı na dalˇs´ı atomické rutiny pro bitové operace AND a OR, pro pˇriˇrazen´ı hodnoty atd.

234

Bari´ era • bariéra (barrier ) je zp˚ usob, jak udrˇzet ˇcleny skupiny pohromadˇe • vˇsechna vl´ akna ˇcekaj´ı na bariéˇre, dokud ji nedosáhne posledn´ı vl´ akno; pak mohou pokraˇcovat • typické pouˇzit´ı je paraleln´ı zpracován´ı dat int pthread barrier init(pthread barrier t *barrier, attr, unsigned count ); • inicializuje bariéru pro count vstup˚ u do n´ı int pthread barrier wait(pthread barrier t *barrier ); • zablokuje se dokud nen´ı zavolána count-krát int pthread barrier destroy(pthread barrier t *barrier ); • zruˇs´ı bariéru

• API pro bariéry je definované od SUSv3, pod´ıvejte se napˇr´ıklad na pthread barrier init, je moˇzné je ale jednoduˇse vytvoˇrit pomoc´ı mutex˚ u a podm´ınkov´ ych promˇenn´ ych. • Pozor na to, ˇze bariéry jsou nepovinnou ˇcást´ı POSIXu (patˇr´ı do Advanced realtime threads) a tedy i systém certifikovan´ y na SUS je nemus´ı implementovat, coˇz je pˇr´ıpad Mac OS X (10.10). • bariéru m˚ uˇzete vyuˇz´ıt napˇr. v situaci, kdy mezi jednotliv´ ymi fázemi zpracov´ an´ı je potˇreba provést jistou inicializaci, vlákna pˇred n´ı tedy na sebe vˇzdy mus´ı poˇckat, protoˇze inicializace dalˇs´ı fáze m˚ uˇze zaˇc´ıt aˇz tehdy, kdy skonˇc´ı f´ aze pˇredchoz´ı. Pˇr´ıklad pthreads/pthread-barrier.c ukazuje pouˇzit´ı bariéry pro nˇekolik f´ az´ı zpracován´ı dat. • podm´ınka pro bariéru je napˇr´ıklad hodnota ˇc´ıtaˇce rovnaj´ıc´ı se nule. Kaˇzdé vl´ akno, které dos´ ahne bariéry, sn´ıˇz´ı ˇc´ıtaˇc, kter´ y je na zaˇcátku inicializován na poˇcet vl´ aken. Pokud vl´ akno po dekrementován´ı ˇc´ıtaˇce zjist´ı, ˇze jeˇstˇe nen´ı roven nule, usp´ı se na podm´ınkové promˇenné. Pokud dané vlákno je t´ım vl´ aknem, které sn´ıˇz´ı ˇc´ıtaˇc na nulu, m´ısto zavolán´ı pthread cond wait poˇsle broadcast, kter´ y n´ aslednˇe probud´ı vˇsechna vlákna sp´ıc´ı na bariéˇre (pthread cond signal zde nestaˇc´ı, chcete probudit vˇsechna vlákna, ne jen jedno!). Pˇred spuˇstˇen´ım dalˇs´ı fáze zpracován´ı se ˇc´ıtaˇc reinicializuje na p˚ uvodn´ı hodnotu. I zde je nutné ˇreˇsit r˚ uzné problémy, napˇr´ıklad nen´ı moˇzné jen tak reinicializovat ˇc´ıtaˇc poté, co bariéry dosáhne posledn´ı vlákno, protoˇze jak jiˇz v´ıme, vl´ akna po probuzen´ı z pthread cond wait mus´ı vˇzdy otestovat, zda ˇc´ıtaˇc je opravdu nulov´ y a pokud nen´ı, opˇet se usp´ı. Takˇze by se vám mohlo

235

st´ at, ˇze by se probudila jen nˇekterá vlákna, nebo taky ˇzádná. Je nutné zresetovat ˇc´ıtaˇc aˇz po probuzen´ı posledn´ıho vlákna. Jak byste to ˇreˇsili?

Semafory • semafory poch´ az´ı z POSIX-1003.1b (real-time extensions) • jména funkc´ı nezaˇc´ınaj´ı pthread , ale sem (sem init, sem post, sem wait, . . . ) • je moˇzné je pouˇz´ıt s vl´ akny

• funkce pro semafory se drˇz´ı klasické UNIXové sémantiky – pˇri chybˇe vracej´ı -1 a nastav´ı errno

236

Typick´ e pouˇ zit´ı vl´ aken • pipeline – kaˇzdé z vl´ aken provád´ı svoji operaci nad daty, která se postupnˇe pˇred´ avaj´ı mezi vlákny – kaˇzdé vl´ akno typicky provád´ı jinou operaci . . . zpracov´ an´ı obr´ azku, kde kaˇzdé vlákno provede jin´ y filtr • work crew – vl´ akna prov´ adˇej´ı stejnou operaci, ale nad jin´ ymi daty . . . zpracov´ an´ı obr´ azku dekompozic´ı – kaˇzdé vlákno zpracovává jinou ˇc´ ast obr´ azku, v´ ysledkem je spojen´ı zpracovan´ ych dat ze vˇsech vl´ aken; zde se hod´ı ˇreˇsen´ı s bariérou • client – server

• dané rozdˇelen´ı je jen orientaˇcn´ı, pouˇzit´ı vláken je samozˇrejmˇe neomezené, toto jsou asi ty tˇri nejˇcastˇejˇs´ı pouˇzit´ı • V pˇr´ıpadˇe modelu klient – server zpracovává kaˇzdé vlákno jeden poˇzadavek od jednoho klienta.

237

Thread-safe versus reentrantn´ı • thead-safe znamen´ a, ˇze kód m˚ uˇze b´ yt volán z v´ıce vláken najednou bez destruktivn´ıch následk˚ u – do funkce, kter´ a nebyla navrˇzena jako thread-safe, je moˇzné pˇridat jeden z´ amek – na zaˇcátku funkce se zamkne, na konci odemkne – tento zp˚ usob ale samozˇrejmˇe nen´ı pˇr´ıliˇs efektivn´ı • slovem reentrantn´ı se typicky mysl´ı, ˇze daná funkce byla navrˇzena s pˇrihlédnut´ım na existenci vláken – . . . tedy ˇze funkce pracuje efektivnˇe i ve v´ıcevláknovém prostˇred´ı – takov´ a funkce by se mˇela vyvarovat pouˇzit´ı statick´ ych dat a pokud moˇzno i prostˇredk˚ u pro synchronizaci vláken, protoˇze bˇeh aplikace zpomaluj´ı

• z v´ yˇse uvedeného vypl´ yv´ a, ˇze thread-safe je slabˇs´ı vlastnost neˇz reentrantn´ı. Napsat thread-safe funkci lze s pouˇzit´ım synchronizaˇcn´ıch primitiv; pˇrepsán´ı existuj´ıc´ı funkci tak, aby byla reentrantn´ı vyˇzaduje mnohem v´ıce invence. • reentrantn´ı funkce jsou také jediné funkce bezpeˇcnˇe pouˇzitelné v signal handlerech. • v dneˇsn´ı dobˇe thread-safe vˇetˇsinou znamená reentrantn´ı, tj. funkce jsou pˇreps´ any tak, aby pracovaly efektivnˇe i s vlákny, je ale dobré vˇedˇet, ˇze nˇekdy to m˚ uˇze vyjadˇrovat rozd´ıl. • o zamyk´ an´ı knihoven viz také strana 235. • existuje mnoˇzstv´ı funkc´ı, které mohou b´ yt thread-safe, ale nikoliv reentrant, napˇr. gethostbyname. Bˇeˇznˇe tato funkce pouˇz´ıvá statickou promˇennou, která se znovu pouˇzije pˇri kaˇzdém volán´ı, takˇze je pro pouˇzit´ı v multithreadovém prostˇred´ı nevhodné - nen´ı thread-safe. Nicménˇe, na FreeBSD 6.0 je tato funkce implementovan´ a tak, ˇze pouˇz´ıvá implicitnˇe thread-local storage pro uloˇzen´ı v´ ystupn´ıch dat a t´ım pádem je thread safe. To ji jeˇstˇe ale neˇcin´ı u ´plnˇe bezpeˇcnou k pouˇzit´ı (nemluvˇe o tom, ˇze program , kter´ y se spoléhá na takové chov´ an´ı nen´ı portabiln´ı), viz pˇr´ıklad reentrant/gethostbyname.c . O nˇeco lepˇs´ı je pouˇz´ıt reentrantn´ı verzi této funkce gethostbyname r (pokud je na daném systému k dispozici), u které lze specifikovat adresu, kam m´ a ukl´ adat sv˚ uj v´ ystup, ˇc´ımˇz se stává reentrantn´ı. Daleko nejlepˇs´ı ˇreˇsen´ı je pouˇz´ıt standardn´ı funkci getaddrinfo (viz strana 206), která je sama o sobˇe reentrantn´ı.

238

• pˇr´ıklad: reentrant/inet ntoa.c - tady je vidˇet, ˇze ani takto napsaná funkce v´ am nepom˚ uˇze pokud je volaná dvakrát v rámci jednoho volán´ı printf. Pokaˇzdé vrac´ı pointer se stejnou adresou (v jednom threadu), kterou si printf pouze poznamen´ a a pˇri fin´ aln´ım tisku tedy vyp´ıˇse reprezentaci posledn´ı adresy, se kterou byla inet ntoa volána. Na Solarisu je to vidˇet pomoc´ı: truss -t\!all -u libnsl::inet_ntoa ./a.out • Na Solarisu obsahuj´ı manu´ alové stránky knihovn´ıch funkc´ı poloˇzku MT-level v sekci ATTRIBUTES, kter´ a udává zda je moˇzné funkci pouˇz´ıt v multithreadovém prostˇred´ı a pˇr´ıpadnˇe s jak´ ymi omezen´ımi. Tyto u ´rovnˇe jsou popsány v manu´ alové str´ ance attributes(5).

Nepˇ renositeln´ a vol´ an´ı • nepˇrenositeln´ a vol´ an´ı konˇc´ı ˇretˇezcem np (non-portable) a jednotlivé systémy si takto definuj´ı vlastn´ı volán´ı • FreeBSD – pthread set name np(pthread t tid, const char *name) → umoˇzn ˇuje pojmenovat vlákno • Solaris – pthread cond reltimedwait np(...) → jako timedwait, ale ˇcasov´ y timeout je relativn´ı • OpenBSD – int pthread main np(void) → umoˇzn ˇuje zjistit, zda volaj´ıc´ı vlákno je hlavn´ı (= main())

• Tyto informace jsou pro zaj´ımavost, abyste vˇedˇeli, ˇze se s podobn´ ymi vˇecmi m˚ uˇzete setkat. Nepˇrenositelná volán´ı by se mˇela pouˇz´ıvat sp´ıˇse pro lad´ıc´ı u ´ˇcely. Nikdy nev´ıte, kdo bude potˇrebovat váˇs kód spustit na jiném systému, coˇz se stane typicky a neˇcekanˇe po té, co zrovna opust´ıte vaˇsi spoleˇcnost a nem´ ate jiˇz ˇcas to opravit. • Zjistit, jak´ a nepˇrenositeln´ a volán´ı váˇs systém poskytuje je jednoduché, tˇreba pomoc´ı apropos np, nebo o nˇeco hrubˇeji (aplikujte na sv˚ uj systém podle lokace manu´ alov´ ych str´ anek): $ cd /usr/share/man $ find . -name ’*_np\.*’ ./man3c/mq_reltimedreceive_np.3c 239

./man3c/mq_reltimedsend_np.3c ./man3c/posix_spawnattr_getsigignore_np.3c ./man3c/posix_spawnattr_setsigignore_np.3c ./man3c/pthread_cond_reltimedwait_np.3c ./man3c/pthread_key_create_once_np.3c ./man3c/pthread_mutex_reltimedlock_np.3c ./man3c/pthread_rwlock_reltimedrdlock_np.3c ./man3c/pthread_rwlock_reltimedwrlock_np.3c ./man3c/sem_reltimedwait_np.3c

240

ChangeLog 2014-12-17 pozn´ amky k rekurzivn´ım mutex˚ um, p233 2014-12-16 pˇrid´ an pˇr´ıklad na velikost stacku u pthread˚ u pthreads/pthread-stack-overflow.c , p222 2014-12-16 u ´prava k´ odu TCP klienta a rozˇs´ıˇreny pozn´ amky o hyb´ ach pro TCP server a klient, p208, p209 2014-12-15 zobecnˇ en slajd na stranˇ e 242 o atomick´ ych aritmetick´ ych operac´ıch, pˇr´ıklad race/atomic-add.c pˇreps´ an aby fungoval jak na Solarisu, tak OS X. 2014-12-15 pozn´ amka k IPv4-mapped IPv6 adres´ ach u pˇr´ıkladu TCP serveru, p208. 2014-12-15 vyjmut slajd o legacy/obsolete funkc´ıch gethostbyname a gethostbyaddr. 2014-12-12 r˚ uzn´ e pozn´ amky k socket API 2014-02-13 pˇrid´ an pˇr´ıklad pthreads/pthread-barrier.c a vysvˇ etlen´ı API k POSIX bari´ er´ am, p243. 2013-11-28 pˇrid´ an pˇr´ıklad file-locking/lockf.c a pozn´ amky k mandatory lockingu, p174. 2013-11-18 v´ıce pozn´ amek k OS X, pˇr´ıklad session/getppid.c 2013-11-12 v´ıce k mmap(), pˇr´ıklad mmap/aligned.c 2013-11-11 podrobnˇ ejˇs´ı vysvˇ etlen´ı k priorit´ am proces˚ u 2013-10-21 pozn´ amka k rekurzivn´ımu maz´ an´ı adres´ aˇre u knihovn´ıho vol´ an´ı rmdir 2013-05-31 pˇrid´ an pˇr´ıklad inetd/accept-rw.c a v´ıce informac´ı k inetd, p214. 2013-01-01 v´ıce detail˚ u k fungov´ an´ı k pthread atfork, pthreads/atfork.c , p229. 2012-12-18 pozn´ amka k vytv´ aˇren´ı thread˚ u v cyklu, p221 2012-12-05 pˇrid´ an pˇr´ıklad resolving/getbyname.c , p205 a koment´ aˇr k funkc´ım prohled´ avaj´ıc´ım datab´ aze sluˇ zeb a protokol˚ u 2012-11-28 pˇrid´ an pˇr´ıklad race/fcntl-fixed-race.c , p175 2012-11-21 pˇrid´ an pˇr´ıklad signals/sigqueue.c 2012-11-14 pˇrid´ an pˇr´ıklad mmap/lseek.c k mmap 2012-01-30 priklady jsou nyni odkazy na web 2012-01-22 pˇrid´ any pozn´ amky k tread-safe/reentrant funkc´ım a odkazy na pˇr´ıklady reentrant/gethostbyname.c , reentrant/inet ntoa.c , p247. 2012-01-16 slajd o bari´ eˇre a semaforech rozdˇ elen na dva, p243 2012-01-16 pˇrid´ ana tabulka shrnuj´ıc´ı chov´ an´ı jednotliv´ ych typ˚ u mutex˚ u, p234. 2012-01-13 pozn´ amka o zp˚ usobu implementace POSIX threads a knihovn´ ach, kter´ e toto API nab´ızej´ı, p219 2012-01-13 pozn´ amka o d˚ uleˇ zitosti funkce scheduleru pˇri implementaci synchronizaˇ cn´ıch primitiv 2012-01-11 pˇrid´ an odkaz na pˇr´ıklad pthreads/set-detachstate.c 2012-01-11 rozveden popis pouˇ zit´ı funkce pthread atfork, p229. 2012-01-10 pˇreformulov´ an koment´ aˇr k slajdu s pˇr´ıkladem pro atomic add, p242. 2012-01-10 pˇr´ıklad na neblokuj´ıc´ı connect pˇresunut za vol´ an´ı getsockopt a select. 2012-01-05 pˇreps´ any slajdy s pˇr´ıklady pro TCP klient a server tak aby nebyly specifick´ e pro ˇ z´ adnou address family 2012-01-04 pˇrid´ an pˇr´ıklad resolving/getnameinfo.c , doplnˇ eny slajdy pro funkce getnameinfo a getaddrinfo na str´ ank´ ach 208 a 206. 2012-01-03 pˇr´ıklady pro vyˇsˇs´ı granularitu sleep byly pˇresunuty do samostatn´ eho adres´ aˇre resolving 2011-12-22 upˇresnˇ en´ı k wildcard soket adres´ am u vol´ an´ı bind an´ı setsockopt 2011-12-21 pˇrid´ an pˇr´ıklad tcp/reuseaddr.c pro demonstraci parametru SO REUSEADDR vol´

241

2011-11-24 nov´ y slajd o setpgid a setsid 2011-11-23 pozn´ amky k form´ atu spustiteln´ ych soubor˚ u a.out 2011-11-09 pozn´ amky k pˇresmˇ erov´ an´ı a tabulce deskriptor˚ u 2011-11-07 Pˇrid´ any PDF bookmarks druh´ eho ˇr´ adu k definic´ım funkc´ı a d˚ uleˇ zit´ ym slajd˚ um. 2011-11-07 Ot´ azka k fstat 2011-11-02 Doplnˇ eny informace o /etc/passwd a /etc/shadow. Pˇrid´ an slajd p 72 s funkcemi pro z´ısk´ av´ an´ı u ´ daj˚ u o uˇ zivatel´ıch/skupin´ ach (getpwent apod.) 2011-10-26 Zm´ınˇ en chroot, kosmetick´ e opravy v sekci o API pro soubory. enn´ e prostˇred´ı LD LIBRARY PATH. 2011-10-19 Pˇrid´ an pˇr´ıklad exit/exit.c a informace o promˇ 2011-10-18 Aktualizace informac´ı o souˇ casn´ ych unixov´ ych syst´ emech, pˇrid´ ano p´ ar detail˚ u k historii. ´ 2011-10-17 Upravy stylu (linky, pˇr´ıklady, PDF bookmarks). 2011-01-08 Nov´ y pˇr´ıklad mutexes/not-my-lock.c , p234. 2010-10-23 Pozn´ amka o funkci znaku ‘-’ ve jm´ enˇ e shellu v argv[0], p51. 2010-10-21 Nov´ e pˇr´ıklady read/lseek.c , p106, read/big-file.c , p106, read/redirect.c , p109, stat/filetype.c a stat/stat.c , p113. 2010-10-20 Nov´ y pˇr´ıklad read/cat.c , p103. 2010-10-15 Nov´ y pˇr´ıklad err/err.c , p67. 2010-03-07 Upˇresnˇ en´ı informac´ı ohlednˇ e zachyt´ av´ an´ı synchronn´ıch sign´ al˚ u, p156 a p231, a nov´ y pˇr´ıklad signals/catch-SIGSEGV.c . 2010-03-06 Pˇrid´ any informace o sigwait vol´ an´ı vzhledem k synchronn´ım sign´ al˚ um, p231. Nov´ y pˇr´ıklad pthreads/sigwait-with-sync-signals.c . 2010-02-28 Drobn´ eu ´pravy. 2010-01-11 V´ıce o errno pˇri pouˇ zit´ı s vl´ akny, p220. 2009-12-13 Nov´ e pˇr´ıklady select/busy-waiting.c , p210, select/write-select.c , p212 a tcp/addresses.c , p198. 2009-12-06 Nov´ y pˇr´ıklad signal/signal-vs-sigaction.c , p161, zm´ınˇ eno makro SOMAXCONN. 2009-10-11 Nov´ e pˇr´ıklady odkazovan´ ezˇ c´ asti pro prvn´ı pˇredn´ aˇsku. 2009-10-06 Drobn´ e fixy, pˇrid´ an´ı Vl´ adi Kotala jako vyuˇ cuj´ıc´ıho tohoto pˇredmˇ etu pro letoˇsn´ı rok. 2009-02-13 Zm´ınˇ eno vol´ an´ı remove(3), p120. 2009-02-06 Nov´ y pˇr´ıklad tcp/non-blocking-connect.c , p211. 2009-01-14 Nov´ e pˇr´ıklady z adres´ aˇre main, p52, lib-abi/abi-main.c , p39, exec/exec-date.c , p138, getaddrinfo/gethostbyname.c , getopt/getopts.sh a getopt/getopt.c , p58. 2009-01-13 Nov´ e slajdy getaddrinfo, p206, getnameinfo, p208, nov´ e pˇr´ıklady cond-variables/queue-simulation.c , p240, getaddrinfo/getaddrinfo.c , p206. 2009-01-10 Nov´ y slajd, kter´ y uv´ ad´ı celou sekci o vl´ aknech, p219, a obsahuje nˇ ekter´ e obecn´ e informace, kter´ e by jinak nebyly zd˚ uraznˇ eny. Nov´ e pˇr´ıklady mutexes/race.c a mutexes/race-fixed.c , p235. 2009-01-06 Pˇrid´ ana zm´ınka o privilege separation, p217, pˇrid´ any pˇr´ıklady pthreads/setjmp.c , p218, pthreads/wrong-use-of-arg.c a pthreads/correct-use-of-arg.c , p221, pthreads/int-as-arg.c , p221, pthreads/pthread-join.c a pthread-detach-join.c , p224, pthreads/pthread-cancel.c , p225, pthreads/fork.c , pthreads/fork-not-in-main.c , a pthreads/forkall.c , p229, a pthreads/sigwait.c , p231.

242

2008-12-16 Nov´ e slajdy o adresn´ıch struktur´ ach pro s´ıt’ovou komunikaci, p194, a o pˇrevodech adres z bin´ arn´ı reprezentace na ˇretˇ ezce a naopak, p197. Pˇrid´ any pˇr´ıklady na TCP, tcp/up-to-listen-only.c , p196, tcp/tcp-sink-server.c , p197, tcp/connect.c , p198, a UDP, udp/udpclient.c , aci s v´ıce deskriptory, select/select.c , p201, udp/udp-server.c , p200. Pˇr´ıklad pro pr´ p211, a alternativn´ı pouˇ zit´ı vol´ an´ı poll v select/poll-sleep.c , p213. 2008-12-09 Pˇr´ıklady file-locking/lock-unlock.c , p173, file-locking/fcntl-locking.c , p175, semaphores/sem-fixed-race.c , p183. 2008-12-01 Pˇr´ıklad dyn-lib/rtld next.c , p151 2008-11-30 Pˇr´ıklady signals/killme.c , p154, signals/catch-SIGKILL.c , p158, signals/ctrl-z.c , p158, signals/sa sigaction.c , p161, race/race.c , p167. 2008-11-28 Pozn´ amka k return (-1), p52. Doplnˇ en´ı pozn´ amek k dynamick´ emu linkov´ an´ı. Nov´ e pˇr´ıklady: dyn-lib/ld-lazy.c a dyn-lib/dlopen.c , p150, signals/alarm.c , p162, signals/sigwait.c , p165. a poloˇ zka struktury dirent, p119. Nov´ y slajd s uk´ azkou konkr´ etn´ıho 2008-11-22 d type, nepˇrenositeln´ adresov´ eho prostoru procesu, p124, a k tomu pˇr´ıklad pmap/proc-addr-space.c . 2008-11-19 Nov´ y pˇr´ıklad wait/wait.c , p141, a doplnˇ en´ı pozn´ amek ke stejn´ emu slajdu. Nov´ e pˇr´ıklady fork/fork.c a fork/vfork.c , p136. 2008-11-11 Zaˇ cal jsem postupnˇ e pˇrid´ avat odkazy na pˇr´ıklady k jednotliv´ ym slajd˚ um. Pokud je tedy v pozn´ amk´ ach uvedeno ,,pˇr´ıklad: readdir/readdir.c ”, znamen´ a to, ˇ ze pˇr´ıklad najdete zde: http://mff.devnull.cz/pvu/src/readdir/readdir.c 2008-11-06 Pˇrid´ any r˚ uzn´ e pozn´ amky k API pro pr´ aci se soubory. Nov´ y slajd pˇredstavuj´ıc´ı funkce err(3), p67. 2008-10-21 Pˇrid´ an pˇr´ıklad bin´ arn´ı nekompatibility OpenSSL knihoven r˚ uzn´ ych verz´ı v dneˇsn´ıch syst´ emech, p41. 2008-10-04 Pˇrid´ any r˚ uzn´ e pozn´ amky a doplnˇ en´ı pˇri kontrole pˇred prvn´ı pˇredn´ aˇskou nov´ eho semestru, napˇr´ıklad uk´ azka na nespr´ avn´ e pouˇ zit´ı execl vol´ an´ı, p138, nebo upozornˇ en´ı na to, ˇ ze jak´ ekoli ˇreˇsen´ı pro synchronizaci pomoc´ı aktivn´ıho ˇ cek´ an´ı nen´ı pˇri zkouˇsce akceptov´ ano, p173, 210. 2008-09-05 Zm´ınˇ ena vol´ an´ı setjmp a longjmp, p218 2008-03-30 Pˇrid´ any informace k m´ od˚ um RTLD LAZY a RTLD NOW pro vol´ an´ı dlopen, p150. 2008-03-23 Pˇrid´ ana pozn´ amka k maz´ an´ı soubor˚ u a sticky bitu, p73, v´ıce informac´ı k SIGKILL, p157, k async-signal-safe funkc´ım, p160, k aktivn´ımu ˇ cek´ an´ı pˇri synchronizaci, p171, pˇr´ıklad na deadlock, p177. 2008-03-01 Drobn´ a doplnˇ en´ı k sign´ al˚ um. Pˇrid´ ana pozn´ amka o funkc´ıch sigwaitinfo(3) a sigtimedwait(3), p165. 2008-02-29 Pˇrid´ an samostatn´ y slajd o POSIXu, p16. 2008-02-17 Mnoho oprav r˚ uzn´ ych chyb a jin´ ych nepˇresnost´ı. Pˇrid´ ana informace o POSIX.4, p161. Dˇ ekuju Martinovi Horˇ ciˇ ckovi (martin at horcicka dot eu) za feedback. 2008-01-25 Mal´ e opravy v sazbˇ e textu, pˇrid´ an´ı kˇr´ıˇ zov´ ych odkaz˚ u, drobn´ a doplnˇ en´ı pozn´ amek na r˚ uzn´ ych m´ıstech apod. 2007-12-29 Doplnˇ en´ı definice kritick´ e sekce (p169), pˇrid´ an u ´vodn´ı slajd k synchronizaci vl´ aken (p232), doplnˇ eny informace o r˚ uzn´ ych typech mutex˚ u (p233), doplnˇ eny pozn´ amky k podm´ınkov´ ym promˇ enn´ ym. 2007-12-12 Pˇrid´ ano mnoho nov´ ych pozn´ amek ke slajd˚ um o s´ıt’ov´ e komunikaci. 2007-12-09 Pˇrid´ an slajd pro atomic add(3c) v sekci synchronizace vl´ aken, p242. 2007-11-21 R˚ uzn´ a doplnˇ en´ı k sign´ al˚ um na slajdech i v pozn´ amk´ ach. 2007-11-18 Opraveny dalˇs´ı v´ yskyty znaku ‘0’ m´ısto ˇretˇ ezce ‘len’, tentokr´ at na slajdech k mmap(2) vol´ an´ı. 2007-11-07 Pˇrid´ an konkr´ etn´ı pˇr´ıklad k pozn´ amk´ am o soft updates.

243

2007-10-23 Nov´ y slajd ,,API vers ABI”, p38, a doplnˇ en´ı pozn´ amek k z´ apisu do pojmenovan´ e roury, p104. 2007-10-15 Doplnˇ eny pozn´ amky ke slajd˚ um o promˇ enn´ ych prostˇred´ı a ˇ cten´ı/z´ apisu z/do roury, kde byly i faktick´ e chyby. ˇ asteˇ 2007-10-07 C´ cnˇ e pˇreps´ any pozn´ amky ke slajd˚ um o historii unixu, standardech a souˇ casn´ ych syst´ emech; doplnˇ eny pozn´ amky k dynamick´ emu linkeru, debugger˚ um a C. 2007-09-16 Vyˇrazena kapitola o administraci, bude nahrazeno nˇ eˇ c´ım jin´ ym, pravdˇ epodobnˇ e aplikac´ı autoconf. 2007-09-16 Opravy pˇreklep˚ u, gramatick´ ych chyb a pod. D´ıky Honzovi Friedlovi (frido at devnull dot cz) 2007-07-18 Do tˇ echto materi´ al˚ u byl pˇrid´ an ChangeLog pro snadnˇ ejˇs´ı sledov´ an´ı zmˇ en. Generov´ an´ı tohoto textu bylo z´ aroveˇ n pˇresunuto z FreeBSD na Solaris a v souvislosti s t´ım jsem pˇreˇsel z CsLaTeX na Babel. M˚ uˇ ze to ovlivnit nˇ ekter´ e fonty a t´ım i sazbu textu.

244

The End.

245

Programování v UNIXu

Recommend Documents