abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

    včera 16:55 | IT novinky

    Facebook má nové logo. Poznáte rozdíl?

    Ladislav Hagara | Komentářů: 4
    včera 15:55 | Nová verze

    Byla vydána nová verze 7.2 v Javě napsané aplikace pro komplexní návrh rozmístění nábytku a dalšího vybavení v interiérech Sweet Home 3D. Vyzkoušet lze online verzi. Před dvěma týdny vyšla placená verze pro chytré telefony a tablety (App Store, Google Play).

    Ladislav Hagara | Komentářů: 4
    22.9. 14:11 | Pozvánky

    Zítra 23. září proběhne Maker Faire Mladá Boleslav, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.

    Ladislav Hagara | Komentářů: 0
    22.9. 13:33 | Nová verze

    Byla vydána beta verze Ubuntu 23.10 s kódovým názvem Mantic Minotaur. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 23.10 mělo vyjít 12. října 2023.

    Ladislav Hagara | Komentářů: 9
    22.9. 11:22 | Zajímavý článek

    Josef Průša informuje o nových verzích firmwarů pro tiskárny Original Prusa, 5.0.0 pro MK4 a MK3.9 a 5.1.0-alpha1 pro MINI, díky kterým jsou tiskárny mnohem rychlejší.

    Ladislav Hagara | Komentářů: 0
    22.9. 09:11 | Nová verze

    Mastodon (Wikipedie), svobodná federalizovaná sociální síť, byl vydán ve verzi 4.2. Z novinek je vypíchnuto vylepšené vyhledávání.

    Ladislav Hagara | Komentářů: 8
    22.9. 08:55 | Zajímavý článek

    Ben Hawkes publikoval pod názvem The WebP 0day analýzu bezpečnostní chyby CVE-2023-4863 v knihovně WebP / libwebp s řadou zajímavých odkazů. Pravděpodobně se jedná o stejnou chybu jako BLASTPASS (CVE-2023-41064 a CVE-2023-41061) v macOS, iOS, iPadOS a watchOS. Zpracování (zobrazení) speciálně připraveného obrázku nebo přílohy vedlo ke spuštění útočníkem připraveného kódu.

    Ladislav Hagara | Komentářů: 0
    22.9. 08:11 | Zajímavý článek

    Myš je pro kočku: Prohlížeče je dalším dílem ze série článků Myš je pro kočku, kde Edvard Rejthar ukazuje, jak lze počítač ovládat bez myši. Používáte ve webových prohlížečích zkratky Ctrl+(Shift)+Tab, Ctrl+(Shift)+PgDn/PgUp, F6, (Shift)+Alt+Enter nebo F7?

    Ladislav Hagara | Komentářů: 10
    21.9. 14:33 | Nová verze

    Vývojáři mobilní Datovky prosí o pomoc s testováním beta verze mobilní Datovky s novým grafickým rozhraním, podporou pro tmavý režim a podporou pro VoDZ. Aplikace je zatím dostupná pouze pro zařízení Android a je umístěna v samostatném instalačním kanále Datovka Beta. Tento kanál slouží pro testovaní nové funkcionality a grafického uživatelského rozhraní. Datovka Beta se instaluje jako samostatná aplikace s vlastními daty, která

    … více »
    Ladislav Hagara | Komentářů: 0
    21.9. 13:22 | Zajímavý software

    Harlequin byl vydán ve verzi 1.0.0. Jedná se o TUI (Text User Interface) IDE (Integrated Development Environment) k systému pro správu SQL OLAP databází DuckDB.

    Ladislav Hagara | Komentářů: 0
    Knihy s linuxovou tematikou
     (19%)
     (15%)
     (50%)
     (27%)
    Celkem 273 hlasů
     Komentářů: 11, poslední 17.9. 19:19
    Rozcestník

    Dotaz: Python a pojmenovana roura (uz zase)

    12.8.2010 10:55 Radim
    Python a pojmenovana roura (uz zase)
    Přečteno: 298×
    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

    12.8.2010 15:10 Patrik Uhrak | skóre: 31 | blog: pato
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)

    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)
    16.8.2010 10:31 Radim
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    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 avatar 16.8.2010 19:05 Chytrex | skóre: 30 | Bohumín
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    tak mě napadá.. a proč tu rouru nenecháš open a nefedruješ do ní jen čísla?
    Hrdý člen KERNEL ULTRAS .:. define QUESTION ((bb) || !(bb)) .:. Odmítám vaši realitu a nahrazuji ji svou vlastní..
    17.8.2010 02:25 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    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č.)
    17.8.2010 02:38 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    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 :-)
    17.8.2010 10:36 chochi | skóre: 29 | Praha
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)
    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.
    19.8.2010 10:23 Radim
    Rozbalit Rozbalit vše Re: Python a pojmenovana roura (uz zase)

    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.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.