Dotaz: Python a pojmenovana roura (uz zase)

[Radim]

Zdravim, Mam opet problem s pojmenovanou rourou a screenletem. Mam script v bashi. Script spocita cislo, otevre si pojmenovanou rouru, soupne tam spocitane cislo a rouru zavre. To vsechno se deje pomoci normalniho presmerovani vystupu ">". Screenlet si otevre onu rouru pouze pro cteni a v non blocking modu a pomoci gobject.io_add_watch() se diva, jestli tam uz je cislo. Kdyz ne, ceka, kdyz ano, zavola funkci, ktera cislo nacte do promenne a dal s nim pracuje. Akorat kdyz onen script rouru zavre, zacne se mi to cyklit a vytizi procesor na 100%, coz je samozrejme nezadouci. Toto trva do chvile, nez si script znovu rouru otevre pro dalsi cislo a az ji znova zavre, zacykli se to zas. Rouru ve screenletu otviram pomoci os.open(self.cesta_k_roure,os.O_RDONLY|os.O_NONBLOCK)". Vi nekdo, co s tim? Dik

Odpovědi

[Patrik Uhrak]

Zdravim.

Mne toto pripada, akoby ten skript kontroval az prilis casto(resp. tak casto, ako je to v jeho silach). Nie je problem vytazit cpu na maximum, ak sa mu nezada daky casovy limit, interval, v ktorom to kontrolovat. Takze by som tam skusil dat sleep a spustil to opat. Ale vsetko je to len moja domnienka skromna :)

import time

time.sleep(sekundy)

[Radim]

Podle me, fce os.open (pote, co se roura z druhe strany zavre) snazi se usilovne spojeni obnovit nebo neco podobneho a to zpusobi narust zatizeni. Akorat to reseni nepomaha. Kdyz dam do fce, kterou vola prave io_add_watch 1 sec pauzu a krmici script pracuje v intervalu napr. 5 sec, tak porad zbyvajici 4 sec. se cykli. Jistou nadeji jsem vkladal do flagu pro os.open (os.O_RDONLY apod.), ale jeste to budu muset pohledat. Zatim se mi zda, ze v kombinaci flagu, kterou pouzivam (os.O_RDONLY|os.O_NONBLOCK) se pri prvotnim otevreni sveho konce roury fce os.open nastavi do nejakeho mezistavu, ceka az se otevre i ten druhy konec a pak se prepne do "finalniho" stavu. Kdyz se ale druhy konec zavre, uz se nedokaze prepnout do toho mezistavu zpatky a proto pak zmatkuje. Kdyby nekdo vedel, jak ten mezistav nanutit zpatky, to by myslim bylo resenim.

[Chytrex]

tak mě napadá.. a proč tu rouru nenecháš open a nefedruješ do ní jen čísla?

[Messa]

Zase otázka bez kousku funkčního kódu... Tak jsem si testovací program vytvořil:

import gobject
import os

def handler(fd, *args):
    print os.read(fd, 1024)
    return True

fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
gobject.io_add_watch(fd, gobject.IO_IN, handler)
gobject.MainLoop().run()

Provedu mkfifo x, v jednom okně spustím tento program, v druhém zapíšu něco do té roury (echo foo >>x), a hurá - procesor je vytížen. Co s tím?

První věc je podívat se, co to vlastně furt dělá. Tzn. nedomýšlet, zda onen deskriptor není v nějakém tajemném mezistavu a nehledat magickou kombinaci flagů pro os.open(), ale podívám se na výpis strace. Vidím spoustu řádků

poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 3, -1) = 1 ([{fd=3, revents=POLLHUP}])

V man poll se praví:

The bits that may be set/returned in events and revents are defined in <poll.h>: 
    ...
    POLLHUP
           Hang up (output only).

Takže to vypadá, že od té doby, co shell po vykonání příkazu echo foo >>x uzavřel rouru, ten poll neustále vyhazuje POLLHUP, glib pak poll volá stále dokola a to vytěžuje ten procesor.

Nějaké řešení... Napadlo mě uzavřít zápisovou stranu pomocí shutdown, nevím, jestli by to fungovalo, ale protože v Pythonu shutdown jaksi ani není, nebudu se tím vůbec zabývat

Informace o HUPu bude nejspíš jen jeden bit nastavený v nějaké tabulce kernelu, možná by šel nějak vyresetovat, ale teď si na nic nevzpomínám. (Možná by zrovna tohle udělal ten shutdown.)

Další řešení by bylo rouru uzavřít a znovu otevřít, tím bychom se zbavili toho POLLHUPu. Nejspíš by se ten nový deskriptor musel znovu zaregistrovat přes io_add_watch(). Taky není zrovna elegantní řešení.

Na Mac OS X by dle příslušné manuálové stránky mohlo pomoct přidat POLLHUP do zachytávaných eventů při volání poll(), ale na Mac OS X asi nejsme.

Celkem dobré řešení by ale bylo mít neustále tu rouru otevřenou pro zápis, protože ten POLLHUP se objeví zřejmě až když tu rouru uzavře poslední "zapisovatel". Experimentálně ověřeno, funguje, když

fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)

se nahradí za

fd = os.open("x", os.O_RDWR | os.O_NONBLOCK)

Zkus to

(Takže nakonec stačilo najít magickou kombinaci flagů pro os.open(), ale teď aspoň víme proč.)

[Messa]

Jak tak nad tím přemýšlím, tím shutdownem bych možná musel uzavřít čtecí stranu. Což je dost na houby, když z toho pak chci ještě číst

[chochi]

Ja bych to videl spis tak, ze by tazatel potrboval neco takoveho:

import gobject
import os

def handler(fd, *args):
    st = os.read(fd, 1024)
    print st
    if st == "":
        # Konec souboru - zavrem stary a otevrem novy
        os.close(fd)
        fd2 = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
        gobject.io_add_watch(fd2, gobject.IO_IN | gobject.IO_HUP, handler)
        return False
    else:
        return True

fd = os.open("x", os.O_RDONLY | os.O_NONBLOCK)
gobject.io_add_watch(fd, gobject.IO_IN | gobject.IO_HUP, handler)
gobject.MainLoop().run()

Vzdy po konci souboru skoncit stary io-watch a pridat novy na novem souboru.

[Radim]

Hmm. Jako programator amater a samouk jsem zase koukal, co vsechno se da zjistit. O "strace" jsem do ted nemel potuchy.
Napad se zaviranim a opetovnym otviranim jsem mel taky, ale jak pises, neni to moc elegantni a hlavne mi to fungovalo jenom nekdy. Sem asi tu myslenku asi implementoval nejak blbe, protoze zpusob jakym to napsal Chochi(viz nize) se jevi jako funkcni (testovano).
Nicmene os.RDWR se jevi jako pekne a (aspon zatim) funkcni reseni, takze jsem si vybral tohle.
Dik.