K cemu je tam ten Processor yield ? Prijde mi, ze by se uplatnil jenom pri dost drsne zatezi, jenze pak by sam o sobe nic nevyresil, jenom by se to chovalo trochu jinak blbe. :-) (A tak jako tak mi to prijde jako zbytecnost u ukazkoveho prikladu.)
Dávat tento příkaz do nekonečných smyček běžících v separátních vláknech je, pokud to dává smysl, velmi dobrým zvykem a myslím si, že právě u ukázkového příkladu to rozhodně není na škodu.
Cílem nebylo zlepšit rozložení zátěže pouze toho serveru, ale Squeaku jako celku.
Jde o to, že to vlákno běží na nepoužívanější prioritě, jakou má např. většina GUI a celá řada dalších procesů. Nejedná se o kriticky důležitý proces, protože nová připojení odchytává vlákno s vyšší prioritou. Jestliže při předání procesoru tomuto vláknu nebylo zjištěno nové připojení, je velmi pravděpodobné, že v nejbližší době nové připojení zjištěno rovněž nebude a nemá tedy cenu to opět testovat a je lépe předat procesor ostatním vláknům, která jej snad využijí efektivněji. I v případě, že je nové připojení indikováno, bude díky uvolnění procesoru zpracováno dříve, než kdybychom metodu yield nepoužili.
Ano, tomuhle samozrejme rozumim za predpokladu (ktery je tedy zrejme spravny), ze getConnectionOrNil se okamzite vraci, at uz nejake spojeni je, nebo neni. Z toho ovsem IMHO vyplyva, ze tenhle thread tady busy-waituje, takze zbytecne zere CPU cas. Ten yield to sice samozrejme vylepsi, ale porad nic extra. To neexistuje lepsi reseni, kdy proste pockam na prichozi spojeni (ala accept(), nebo neco jako select()) ?
Primitiva pro naslouchání na soketu je neblokující, tzn. že vždy je třeba existenci nového připojení cyklicky testovat. Viz např. ConnectionQueue>>listenLoop. V příkladu uvedeném v článku je použití ConnectionQueue skoro zbytečné, protože ta se používá především v situacích, kdy všechna spojení obsluhujeme jedno za druhým v jednom procesu. Místo Processor yield by šlo použít i třídu Delay.
Pro smalltalkovskou architekturu vlastně ani není jiné cesty, protože primitivy se provádí atomicky. Pokud by primitiva pro naslouchání na soketu byla blokující, došlo by k zablokování všech procesů.
Primitiva samozrejme nesmi byt blokujici, ale cekaci smycka muze mimo uvedenych moznosti taky cekat na semafor, kteremu ve vhodny okamzik posle signal primo VM.
ČLÁNKY DO MAILU