Divacky Roman napsal/wrote, On 02/26/07 11:53:
> select() vola kern_select() ktery vola selscan() ktery vola fo_poll(), coz je
> operace
> definovana v struct fileops{} coz je fs-specific
A take nasledne device-specific. Cimz je zrejme, ze nemuze byt soucasne
hw-nezavisly, jak's predpokladal.
Takze tady vidim nejake nedorozumeni v soucasnem tvrzeni, ze nevidis
hardwarovou zavislost.
> navic si nemyslim, ze by bylo nutne aby hw nejak sdeloval pollu
> ze ma pripraveny data. proc by to nemohlo fungovat tak ze hw nacte data,
> "nejak" (
> interrupt thread, PIO, jakkoliv) je supne do bufferu ktery je genericky pro
> VFS
To by nemohlo. "Nacist data" je operace, ktera uz muze mit konkretni
fyzicky efekt na stav dotceneho zarizeni. ze jit o zarizeni typu
"dotaz-odpoved", kdy je treba na ctena data v urcenem case nejak
zareagovat (odpovedi, potvrzenim a pod.).
A to uz jasne znamena, ze "skutecne cist" si muze dovolit jen takovy
kod, ktery zna konkretni zarizeni natolik, aby se dokazal rozhodnout,
jestli si takove cteni v dane chvili a kontextu muze dovolit.
> pokud v tedle analyze mam chybu tak ocenim kdyz mi dane napises kde, dik :)
To je snadne ;-)
Chyba je v tom, ze "cteni" povazujes za "nevinnou operaci", kterou lze
provest kdykoliv, ale ono ji na obecnem hardware neni.
Mimochodem, i kdyby to nahodou byla pravda, dostat byses s touto uvahou
do vaznych potizi hned o okamzik pozdeji - jak bys obecne resil select()
na zapis ?
>> Konkretne hardware "tiskarna pres USB" rizena ovladacem "ulpt" nema
>> poll() implementovany a pouziva genericky a prazdny nopoll().
>
> no... nemuze todle byt rozdil mezi poll() a select(), ze poll() je fakt per
> character device a select() je jak popisuju vyse obecny? pac je fakt ze
> cdevsw obsahuje pointer na poll rutinu. neni mi ale jasne proc by se to takhle
> melo lisit.
Ne, v tomhle mas pravdu - select() je jen jiny interface k poll(). Jde
o dva pristupy k teze informaci - zda ma zarizeni data ke cteni (zda je
pripraveno akceptovat data zapisem). A to je informace, kterou zarizeni
bud' da nejak k dispozici, nebo neda. A kdyz neda, tak neni. V tomhle
rozdil mezi select() a poll() nespocita. Kdyz je jedno, muze byt i
druhe, pokdu ale zarizeni informaci neposkytuje, nebuze existoval realne
funkcni poll(), ktery by ji zpristuponoval aplikaci a nemuze ani
existovat skutecne funkcni select().
> pokud CUPS pouziva select() tak to nevysvetluje proc by chybejici
> poll() mel vadit
Protoze chybejici poll() znamena chybejici select(). Tedy, abychom byli
presni - aktualni implementace nopoll() ve vysledku znamena, ze select()
okamzite oznami pripravenost zarizeni pro cteni - a nasledny, s duverou
zavolany read(), ktery mel byt neblokujici (podle select()u urcite
nejaka data jsou) se potvora zablokuje. Pokud ovsem cely system pocita s
tim, ze soustava select()/read() je neblokujici muze zablokovani
znamenat vazny problem pro celkovou funkcnost aplikace.
Dan
--
Dan Lukes SISAL MFF UK
AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED]
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
