Zabíjení! - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Odkud pochází fotografka Anne Erhard?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Software

Zabíjení!

6. května 2010, 00.00 | Ne, nezměnili jsme žánr – nová služba Irbise (pro ty, kdo nemají rádi přeložená jména, systému Snow Leopard), na kterou se dnes podíváme, se v běžném jazyce označuje „fast killing“ (v politicky korektním newspeaku oficiálního API ovšem „sudden termination“).

Ne, nezměnili jsme žánr – nová služba Irbise (pro ty, kdo nemají rádi přeložená jména, systému Snow Leopard), na kterou se dnes podíváme, se v běžném jazyce označuje „fast killing“ (v politicky korektním newspeaku oficiálního API ovšem „sudden termination“).

Dokončením přehledu nových služeb třídy NSURL pro práci se jmény souborů a tříd, jež tuto možnost využívají, jsme v minulém dílu našeho seriálu uzavřeli přehled novinek Foundation Kitu – některé méně podstatné nebo řidčeji používané drobnosti jsme ovšem prozatím přeskočili; ponechali jsme stranou i netriviální a poměrně zajímavou podporu tzv. „text checking“ pro její poměrně specifické využití (případně, bude-li čas a zájem, se na ni podíváme později v samostatném článku). Dnes se pouštíme do novinek na úrovni aplikační knihovny AppKit.

Podpora pro „fast killing“, kterou začneme, je do jisté míry „na půl cestě“ – je totiž založena na nových službách třídy NSProcessInfo, a tato třída je technicky součástí knihovny Foundation; z praktického hlediska však její využití dává smysl právě pro aplikace (případně pro jejich pomocné procesy, agenty či démony – právě proto je tam, kde je, a ne ve třídě NSApplication).

Princip funkce

Základní idea je velmi jednoduchá: jak asi všichni čtenáři tohoto seriálu dávno vědí, při odhlašování uživatele (nebo při vypínání počítače, jehož implicitní součástí samozřejmě odhlášení je) systém postupně projde všechny běžící aplikace, a každou z nich pomocí odpovídající protokolu na úrovni Apple Services „slušně požádá“, aby skončila.

(Na úrovni vývojového prostředí Cocoa se samozřejmě nemusíme starat o Apple Services, ale prostě implementujeme standardní metodu applicationShouldTerminate: v objektu, který slouží jako aplikační delegát.)

Aplikace v rámci této služby může udělat potřebný „úklid“; může dokonce požádat o více času, nebo může ukončení odmítnout. Pokud aplikace vůbec nereaguje, systém na to uživatele upozorní, a odhlášení/ukončení zamítne.

Tento mechanismus je velmi důležitý z hlediska bezpečnosti dat a pohodlí uživatele; zároveň ale má dvě nevýhody:

• odložit uložení rozpracovaných dat až na ukončení aplikace není obecně bezpečné: ačkoli aplikace psané v Cocoa díky výhodám objektového systému obecně patří mezi velmi stabilní, libovolná aplikace vždy může „spadnout“ – a data jsou v takovém případě ztracena. Totéž platí v případech, kdy „spadne“ sám operační systém – vinou kódu Apple se to stává jen výjimečně, ale i to občas nastane, a daleko větším risikem jsou doplňky kernelu od třetích firem – nebo kdy zlobí hardware (notorickou příčinou „zamrznutí“ nebo „pádu“ systému jsou nespolehlivé operační paměti);

• i v případě, kdy je vše v pořádku a k žádném problému nedojde, je typicky postupné dotazování desítek běžících aplikací nepříjemnou ztrátou času. Přitom ale obvykle jen několik málo z nich má skutečně nějaký „úklid“ zapotřebí; většina svá data (kromě jiného i z důvodů, popsaných v minulém odstavci) na disk dávno uložila, a požadavek je tedy nadbytečný; mnohem jednodušší a rychlejší by bylo aplikaci přímo „zabít“ – tedy ukončit pomocí odpovídající služby operačního systému.

V systému 10.6 je nová podpora právě pro tuto možnost: aplikace nyní může dát systému na vědomí, zda je ve stavu, kdy je třeba ji před ukončením upozornit, nebo ne. Pokud ne, operační systém může aplikaci „odstřelit“ kdykoli to uzná za vhodné bez jakéhokoli zdržování; to potenciálně – ve chvíli, kdy odpovídající službu začne poctivě používat významná většina vývojářů – významně urychlí odhlášení uživatele nebo ukončení systému.

Nové služby v API

Odpovídající API je velmi jednoduché: každá aplikace nyní obsahuje jednoduchý čítač, jehož obsah může programátor (nebo kdokoli jiný, běžně tak činí např. některé knihovní služby) kdykoli zvýšit nebo snížit. Je-li hodnota čítače nulová, operační systém může aplikaci kdykoli ukončit bez dalších dotazů; je-li nenulová, vše funguje stejně jako tomu bylo až do verse 10.5 – před ukončením se vždy pošle odpovídající požadavek.

Pro práci s čítačem slouží dvojice nových služeb třídy NSProcessInfo:

-(void)disableSuddenTermination;
-(void)enableSuddenTermination;

Prvá z nich obsah čítače o jedničku zvýší; druhá jej o jedničku sníží. Uzavřeme-li tedy jakoukoli akci, v jejímž průběhu obsahuje aplikace neuložená data, mezi volání disableSuddenTermination a enableSuddenTermination, bude vše fungovat korektně – a to i v případě, že se více takovýchto akcí bude vzájemně překrývat (standardní knihovny se chovají právě tímto způsobem; např. třída NSUserDefaults pošle zprávu disableSuddenTermination ve chvíli, kdy se změní hodnota některého nastavení v její cache, a zprávu enableSuddenTermination ve chvíli, kdy se cache zapíše na disk).

Pro zpětnou kompatibilitu s kódem, psaným pro starší verse systému, kde tyto služby ještě nebyly k dispozici, je samozřejmé, že výchozí hodnota čítače je 1 – pokud tedy v aplikaci nikdy nepoužijeme žádnou z nich, bude vše fungovat „postaru“, neboť čítač se nikdy nevynuluje.

Chceme-li nové služby využít – a u aplikací, psaných pro systém 10.6 nebo novější bychom to rozhodně udělat měli –, máme dvě možnosti:

• buď v rámci inicializačního kódu po spuštění aplikace použijeme „nespárovanou“ službu enableSuddenTermination;

• nebo – což funguje v podstatě stejně, je to ale poněkud koncepčně čistší – do seznamu vlastností aplikace v souboru „Info.plist“ přidáme položku NSSupportsSuddenTermination s hodnotou YES.

Druhá varianta navíc má drobnou výhodu také v tom, že systém pak může aplikaci „odstřelit“ i v průběhu inicializace, pokud to je zapotřebí (naopak samozřejmě u aplikací, jež při inicializaci ukládají nějaká data na disk – kupříkladu jež udržují log všech spuštění – to může být nevýhoda).

Třída NSProcessInfo nabízí také službu _suddenTerminationDisablingCount pro zjištění aktuální hodnoty čítače. Ačkoli je zdokumentovaná, není součástí API; dokumentace zdůrazňuje, že je určena pouze pro ladění, a že je chyba použít ji jakkoli v kódu (protože může být odstraněna v libovolné nové versi systému).

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Tipy a Triky  

 » Rubriky  » Začínáme s  

 » Rubriky  » Software  

Poslat článek

Nyní máte možnost poslat odkaz článku svým přátelům:

Váš e-mail:

(Není povinný)

E-mail adresáta:

Odkaz článku:

Vzkaz:

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: