Varování: tento článek asi nic neřekne lidem, kteří nic netuší o programování webových aplikací v jazyce PHP. Na druhou stranu - i když tady cituji jistou chybnou implementaci čehosi v jazyce C, tak znalost Céčka není myslím bezpodmínečně nutná. Ale i neprogramátory by možná mohlo zaujmout, že se tady pokouším rozepsat, jaké věci se třeba občas honí hlavou lidem, kteří používají a modifikují programy s otevřeným zdrojovým kódem. Samozřejmě, že většinou se to takhle nerozebírá a nedebatuje se o tom. Jde o to, že samotná práce s programovacími jazyky podle mě v lidské psychice aktivuje určité typy asociací a svérázné "analytické paranoii", které jsou výrazně odlišné od myšlenkových procesů vyvolaných jinými typy lidských i čistě symbolických jazyků - a "programátorské myšlení" pokládám za poněkud zneuznanou (nikoliv ve smyslu finančním - tam jsou dnes programátoři spíše nadhodnocení - ale třeba ve smyslu akademickém...) alternativu klasického "matematického myšlení".

Nemám na mysli schopnost stát se cvičenou opicí, která vynikne v množství namemorovaných HTML tagů, klíčových slov v CSS, nebo koneckonců i shellových příkazů v unixu. Nechci říkat, že nejde o úctyhodnou schopnost - schopnost namemorovat se telefoní seznam je také uctyhodná, a existují lidé, kteří jsou toho schopni. U toho memorování významu různých umělých konstruktů jde dejme tomu o určité odcizení se běžnému lidskému mluvenému i psanému jazyku, a o osvojení si určitě umělé, post-lidské slovní zásoby. Někdy může být zajímavá i schopnost pracovat se symbolickým zápisem např. různých grafických objektů - tam jde v podstatě o obdobu divadelní nebo filmové scénaristiky. Já mám ale na mysli ještě něco jiného - mluvím tady o specificky programátorské paranoie, a o jejích kořenech.

Před lety jsem tady pravda rozjel seriál (1,2,3) o svém programovacím jazyku C<<1, který běžně používám pro psaní některých svých projektů... ale ten zatím nemá implementováno zrovna závratné množství užitečné funkčnosti oproti čistému C... každopádně, jestli někdy na TečceCZ bude vycházet učebnice C, tak to bude rovnou pojaté jako učebnice C<<1 - včetně seznamu Debianích balíků, které bude třeba instalovat pro kompilaci příkladů, apod. Čisté C je dnes opravdu vhodné jen pro zájemce o spolupráci na vývoji linuxového kernelu - a to je cesta, kterou se asi nikdy netroufnu vydat. Ale do toho teď zabředat nechci.

Tématem tohoto článku je zamykání souborů v Unixu. Zamykání sobourů je důležité, pokud do nějakého souboru na disku má zapisovat více programů současně. Je to obecně způsob uvažování, kterého byli programátoři odchovaní 8bitovými hračkovými počítači a DOSem většinou ušetřeni - ale je to zároveň naprostý základ jakéhokoliv multitaskingu. A web je o multitaskingu. Nejjednodušší myslitelnou aplikací zamykání souborů je implementace primitivního počítadla přístupů, vloženého přímo do vašich webových stránek - které ale přitom nebude závislé na externím uložiští dat (např. na SQL databázi.. ony ty externí databáze mě vůbec nějak přijdou jako cesta do pekel, ale to jen můj subjektivní pocit, který nemá cenu řešit). Tedy samozřejmě - filesystém je také úložiště dat. Někdo má rád soubory, a někdo má rád SQL. Důvodem pro nezávislost na SQL může být například to, že někteří webhosteři (například já :-) poskytují svým zákazníkům na serverech SQL databáze jen za (mírný) příplatek. A proč platit několik stovek ročně za funkčnost, kterou někdy lze implementovat pomocí pár řádků v PHP, že ano...

Před časem jsem řešil problematiku zamykání souborů v Céčku. I vás třeba může napadnout vytvořit si jako zámek speciální soubor. To je samo o sobě zbytečné - zamykání bylo v unixech navržené tak, aby šlo zamknout přímo soubor, do kterého zapisujete. Ale to není všechno. Špatně jsem toho zjevně pochopil víc... posuďte sami:

#include <stdio.h>
#include <sys/stat.h>
#include <sys/file.h>
#include <fcntl.h>
#include <unistd.h>

{
 int f=open(fname,O_RDONLY);
 if(f<0)
 {
  f=open(fname,O_WRONLY|O_CREAT,S_IWRITE|S_IREAD);
  if(f<0)
   return -1;
 }
 while(flock(f,LOCK_EX)==-1)
  sleep(1);
 ...
}

Zejména smyčka while(flock(f,LOCK_EX)==-1) je zjevně nesmyslná.

Služba zamykání souboru je totiž zejména v unixových systémech implementována jako blokující volání jádra - tedy v rámci tohoto volání se čeká, dokud soubor není zamčen. Více detailů viz man flock. Snažit se volat funkci flock() ve smyčce tedy neznamená zkoušet každou sekundu, zda se nám již soubor podařilo zamknout - znamená to regulérně se donekonečna zacyklit, pokud zamčení souboru z nějakého důvodu není možné provést. Což se nepochybně občas dělo - a náš server si nepochybně oddechl ve chvíli, kdy jsem na tuhle chybu přišel a starý program pro počítání návštěv začal vyřazovat.

Protože zveřejnit tady korektní implementaci v Céčku by asi nebylo v dnešní éře masového rozšíření PHP pro moc lidí zajímavé, a já neplánuju dělat tady z toho učebnici Céčka, tak zveřejním korektní příklad zamykání souboru rovnou v PHP.

Zde tedy uvádím jako příklad jednoduché počítadlo návštěv v PHP. Vypadá to opravdu triviálně - ale musím se přiznat, že už asi stárnu, a kvalitu kódu neměřím podle počtu vygenerovaných řádek. Zajímají mě spíš jakási "programátorská haiku" (nebo případně i kóany :-). Jde o to, že napsat kód, který bude něco dělat, je v tomhle případě tak triviální, že i mě samotného překvapilo, že několik prvních pokusů bylo chybných a vedlo k občasnému vyresetování counteru. Poprvé protože jsem flock() nepoužil (myslel jsem, že to PHP dělá samo za mě - nedělá, není pro blbé), podruhé vynulování počítadla zase způsobilo chybné použítí flock() - a to už mě překvapilo natolik, že jsem si řekl, že to je téma na celý článek. Nejsem už zvyklý psát kód, ve kterém by byly chyby - a kdybych to netestoval na firemním portálu s někola tisíci návštěv denně, tak bych si toho třeba všiml až za několik let. Podle mě je to poučné pro všechny bastlíře a lepiče, co zuřivě slepují z dostupných knihoven cokoliv se jim podaří, a neuvědomují si, že jejich výtvory často nezkolabují jenom čirou náhodou a díky nízké návštěvnosti a tím i pravděpodobnosti nějaké kolize...

Podmínkou zprovoznění tohoto primitivního počítadla je existence podadresáře data/ v adresáři, kde je PHP skript uložen, jeho vlastnictví stejným uživatelem, kterému patří PHP skript (předpokládá se užití safe mode), a práva zapisu pro uživatele, pod kterým běží Apache (v Debianu se tento uživatel jmenuje www-data). Funkce flock() volající příslušnou službu unixového jádra se v jayzích C i v PHP jeví definovaná stejně, takže tento příklad může myslím pomoci i Céčkařům:

<?
/* xChaos PHP fragment collection - begin  */
/* the simplest correctly working sql-free hit counter, 20060309 */

$counter=0;
$f=fopen('data/counter','r+');
if($f)
{
 if(flock($f, LOCK_EX))
 {
  $counter=intval(fgets($f,10))+1;
  rewind($f);
 }
}
else
{
 $f=fopen('data/counter','w');
 if($f) flock($f, LOCK_EX);
}

printf("%09d",intval($counter));

if($f)
{
 fputs($f,strval($counter));
 fclose($f);
}
/* xChaos PHP fragment collection - end */
?>

Samotné počítadlo přístupů je samozřejmě aplikace na nic - ale podstatné je, že zamykat by se asi měly všechny soubory, do kterých může přes webové rozhraní a PHP potenciálně zapisovat v jednu chvíli víc než jeden uživatel.

Osobně masové rozšíření PHP nepokládám za příliš šťastné - zejména v případě aplikací, které mají používat tisíce lidí denně současně. Nicméně i když by spolupráci spustitelných programů s Apachem mohlo jít pojmout nějak inteligentněji (nějaká šílenost typu fastcgi), tak je třeba přiznat, že u většiny skriptů je jejich interpretace PHP modulem v Apachi méně náročná, než by bylo odpovídající forkování procesu a spouštění binárního CGI skriptu... a výkon CPU je dnes často to jediné, čeho mají počítače dostatek.

Problém je, že pokud obrovské zvýšení komplexity nějakého systému vede pouze k vyřešení problému jehož složitost je lineární, tak se uživatelům obvykle vyplatí spíše příslušné lineární zvyšení výpočetního výkonu (např. zvýšení počtu CPU).

Na druhou stranu - dva procesoru sežerou 2x tolik elektřiny - a přitom většinu času budou stejně idlovat (česky flákat se). Takže ekologické aspekty související s programováním serverových aplikací lze řešit na dvou frontách: na jedné straně se výrobci snaží za chodu podtaktovávat dnešní předimenzovaná CPU, pokud nejsou pod zátěží, na druhé straně by se o optimalizaci mohli snažit také třeba programátoři webových serverů - kdyby dali uživatelům do rukou mocnější nástroj, než je PHP... no, ale to už s problematikou blokujícího systémového volání pro zamykání soborů v Unixu souvisí jenom vzdáleně... :-)

No, příště se v rubrice Howknow pokusím pro změnu rozepsat o receptech na méně známá DIY bezmasá jídla...