Come eseguire attività asincrone nelle app Python GObject Introspection

Sto scrivendo un'app Python + GObject che deve leggere una quantità non banale di dati dal disco all'avvio. I dati vengono letti in modo sincrono e sono necessari circa 10 secondi per completare l'operazione di lettura, durante il quale il caricamento dell'interfaccia utente viene ritardato.

Vorrei eseguire l'attività in modo asincrono e ricevere una notifica quando è pronta, senza bloccare l'interfaccia utente, più o meno come:

def take_ages():
    read_a_huge_file_from_disk()

def on_finished_long_task():
    print "Finished!"

run_long_task(task=take_ages, callback=on_finished_long_task)
load_the_UI_without_blocking_on_long_task()

Ho usato GTask in passato per questo genere di cose, ma temo che il suo codice non sia stato toccato da 3 anni, per non parlare del porting su GObject Introspection. Ancora più importante, non è più disponibile in Ubuntu 12.04. Quindi sto cercando un modo semplice per eseguire le attività in modo asincrono, in modo Python standard o in modo GObject / GTK + standard.

Modifica: ecco un po 'di codice con un esempio di ciò che sto cercando di fare. Ho provato python-defercome suggerito nei commenti, ma non sono riuscito a eseguire il task lungo in modo asincrono e lasciare caricare l'interfaccia utente senza dover attendere che finisca. Sfoglia il codice di prova .

Esiste un modo semplice e ampiamente utilizzato per eseguire attività asincrone e ricevere notifiche al termine?

Il tuo problema è molto comune, quindi ci sono tonnellate di soluzioni (capannoni, code con multiprocessing o threading, pool di lavoratori, ...)

Dato che è così comune, esiste anche una soluzione build-in di Python (in 3.2, ma backportata qui: http://pypi.python.org/pypi/futures ) chiamata concurrent.futures. I "futures" sono disponibili in molte lingue, quindi python li chiama allo stesso modo. Ecco le chiamate tipiche (ed ecco il tuo esempio completo , tuttavia, la parte db è sostituita da sleep, vedi sotto perché).

from concurrent import futures
executor = futures.ProcessPoolExecutor(max_workers=1)
#executor = futures.ThreadPoolExecutor(max_workers=1)
future = executor.submit(slow_load)
future.add_done_callback(self.on_complete)

Ora al tuo problema, che è molto più complicato di quanto suggerisce il tuo semplice esempio. In generale hai thread o processi per risolvere questo problema, ma ecco perché il tuo esempio è così complicato:

1. La maggior parte delle implementazioni di Python ha un GIL, che rende i thread che non utilizzano completamente i multicore. Quindi: non usare thread con Python!
2. Gli oggetti che si desidera restituire slow_loaddal DB non sono selezionabili, il che significa che non possono semplicemente essere passati tra i processi. Quindi: nessuna elaborazione multipla con risultati di softwarecenter!
3. La libreria che chiami (softwarecenter.db) non è threadsafe (sembra includere gtk o simili), quindi chiamare questi metodi in un thread provoca uno strano comportamento (nel mio test, tutto da "funziona" su "core dump" a semplice smettere senza risultati). Quindi: nessun thread con softwarecenter.
4. Ogni callback asincrono in gtk non dovrebbe fare altro che eliminare un callback che verrà chiamato nel glilo mainloop. Quindi: no print, non cambia lo stato gtk, tranne l'aggiunta di un callback!
5. Gtk e simili non funzionano con i thread fuori dalla scatola. Devi farlo threads_inite se chiami un metodo gtk o simile, devi proteggere quel metodo (nelle versioni precedenti questo era gtk.gdk.threads_enter(), gtk.gdk.threads_leave()vedi ad esempio gstreamer: http://pygstdocs.berlios.de/pygst-tutorial/playbin. html ).

Posso darti il ​​seguente suggerimento:

1. Riscrivi il tuo slow_loadper restituire risultati selezionabili e utilizzare i future con i processi.
2. Passa da softwarecenter a python-apt o simili (probabilmente non ti piace). Ma dal momento che sei stato assunto da Canonical, potresti chiedere agli sviluppatori di softwarecenter di aggiungere direttamente la documentazione al loro software (ad esempio affermando che non è sicuro per i thread) e, ancora meglio, rendere sicuro il thread di softwarecenter.

Come nota: le soluzioni presentate dagli altri ( Gio.io_scheduler_push_job, async_call) fare il lavoro con time.sleep, ma non con softwarecenter.db. Questo perché tutto si riduce a thread o processi e thread per non funzionare con gtk e softwarecenter.

Ecco un'altra opzione che utilizza l'I / O Scheduler di GIO (non l'ho mai usato prima da Python, ma l'esempio che segue sembra funzionare correttamente).

from gi.repository import GLib, Gio, GObject
import time

def slow_stuff(job, cancellable, user_data):
    print "Slow!"
    for i in xrange(5):
        print "doing slow stuff..."
        time.sleep(0.5)
    print "finished doing slow stuff!"
    return False # job completed

def main():
    GObject.threads_init()
    print "Starting..."
    Gio.io_scheduler_push_job(slow_stuff, None, GLib.PRIORITY_DEFAULT, None)
    print "It's running async..."
    GLib.idle_add(ui_stuff)
    GLib.MainLoop().run()

def ui_stuff():
    print "This is the UI doing stuff..."
    time.sleep(1)
    return True

if __name__ == '__main__':
    main()

Puoi anche utilizzare GLib.idle_add (callback) per chiamare l'attività di lunga durata una volta che GLib Mainloop termina tutti gli eventi con priorità più alta (che credo includono la creazione dell'interfaccia utente).

Utilizzare l' GioAPI introspetta per leggere un file, con i suoi metodi asincroni, e quando si effettua la chiamata iniziale, farlo come timeout con GLib.timeout_add_seconds(3, call_the_gio_stuff)dove call_the_gio_stuffè una funzione che ritorna False.

È necessario aggiungere il timeout qui (potrebbe essere necessario un numero diverso di secondi, tuttavia), poiché mentre le chiamate asincrone Gio sono asincrone, non sono non bloccanti, il che significa che l'attività pesante del disco nella lettura di un file di grandi dimensioni o grande numero di file, può causare un'interfaccia utente bloccata, poiché l'interfaccia utente e l'I / O sono ancora nello stesso thread (principale).

Se vuoi scrivere le tue funzioni in modo che siano asincrone e si integrino con il ciclo principale, usando le API di I / O del file Python, dovrai scrivere il codice come GObject, o passare i callback in giro, o usare python-deferper aiutarti fallo. Ma è meglio usare Gio qui, in quanto può offrirti molte funzioni interessanti, specialmente se stai facendo file apri / salva cose nella UX.

Penso che valga la pena notare che questo è un modo contorto per fare ciò che @mhall ha suggerito.

Essenzialmente, hai una corsa, quindi esegui quella funzione di async_call.

Se vuoi vedere come funziona, puoi giocare con il timer di spegnimento e continuare a fare clic sul pulsante. È essenzialmente lo stesso della risposta di @ mhall, tranne per il fatto che esiste un codice di esempio.

Basato su questo che non è il mio lavoro.

import threading
import time
from gi.repository import Gtk, GObject



# calls f on another thread
def async_call(f, on_done):
    if not on_done:
        on_done = lambda r, e: None

    def do_call():
        result = None
        error = None

        try:
            result = f()
        except Exception, err:
            error = err

        GObject.idle_add(lambda: on_done(result, error))
    thread = threading.Thread(target = do_call)
    thread.start()

class SlowLoad(Gtk.Window):

    def __init__(self):
        Gtk.Window.__init__(self, title="Hello World")
        GObject.threads_init()        

        self.connect("delete-event", Gtk.main_quit)

        self.button = Gtk.Button(label="Click Here")
        self.button.connect("clicked", self.on_button_clicked)
        self.add(self.button)

        self.file_contents = 'Slow load pending'

        async_call(self.slow_load, self.slow_complete)

    def on_button_clicked(self, widget):
        print self.file_contents

    def slow_complete(self, results, errors):
        '''
        '''
        self.file_contents = results
        self.button.set_label(self.file_contents)
        self.button.show_all()

    def slow_load(self):
        '''
        '''
        time.sleep(5)
        self.file_contents = "Slow load in progress..."
        time.sleep(5)
        return 'Slow load complete'



if __name__ == '__main__':
    win = SlowLoad()
    win.show_all()
    #time.sleep(10)
    Gtk.main()

Nota aggiuntiva, devi lasciare che l'altro thread finisca prima che si concluda correttamente o controlli un file.lock nel tuo thread figlio.

Modifica per rispondere al commento:
inizialmente ho dimenticato GObject.threads_init(). Evidentemente quando il pulsante ha sparato, ha inizializzato il threading per me. Questo ha mascherato l'errore per me.

Generalmente il flusso è creare la finestra in memoria, avviare immediatamente l'altro thread, quando il thread completo aggiorna il pulsante. Ho aggiunto un ulteriore sonno prima ancora di chiamare Gtk.main per verificare che l'aggiornamento completo POTREBBE essere eseguito prima ancora che la finestra fosse disegnata. L'ho anche commentato per verificare che l'avvio del thread non impedisca affatto il disegno della finestra.