2010-08-05 12 views
8

Sto cercando di eseguire il debug di Python utilizzando WinPDB e ho più thread utilizzando threading.Thread. Non riesco mai a controllare i fili individualmente. Se interrompo l'esecuzione, l'intero script si interrompe. Se passo il codice sorgente di un thread, tutti gli altri continuano a essere interfogliati e continuano parte della loro esecuzione. Questo è vero con Synchronicity attivato o disattivato. Non c'è un modo per passare da una discussione individualmente mantenendo gli altri a un punto di interruzione?Come passare attraverso i thread Python in modo indipendente? (WinPDB)

WinPDB è lo strumento sbagliato da utilizzare per questo? Non so proprio cosa usare. Eclipse PyDev funziona a malapena perché lo stesso debugger sembra avere errori di corsa quando avvia più thread.

Che cos'è uno strumento che in realtà esegue correttamente il debug di un programma Python multi-thread?

Grazie.

+0

PPB non supporta il debug di programmi multithreaded. Questo dovrebbe funzionare con PyDev però. Che problema stai vivendo? –

risposta

1

Ho avuto un problema simile, non è la risposta più ideale, ma lo descriverò per te e forse potrai risolverlo.

Ho più o meno scritto un mini debugger. Udp Client/Server e una funzione che non ha fatto altro che prendere un blocco globale, attendere 1 minuto e quindi rilasciarlo. Questa funzione è stata passata a ciascun thread. Ho quindi effettuato una chiamata a questa funzione tra le aree critiche che volevo eseguire il debug. Dopo aver avviato il programma, il server udp ascoltava il client e, se scrivevo "pause", prendeva lo stesso blocco globale utilizzato dalla funzione condivisa e non lo mollava finché non scrivevo "play" nel client. Così facendo, puoi ottenere un arresto abbastanza stretto ... a seconda dell'applicazione.

Spero che sia d'aiuto ... Piccolo frammento sotto. La mia applicazione era per una piattaforma di test, quindi quello che ho fatto è stato aggiungere il puntatore alla funzione nel costruttore della classe base, e usarlo al posto di time.sleep() .. dandomi una leggera debugabilità. Quello che puoi fare è passare questo ad ogni thread e aggiungere chiamate alla funzione di pausa all'inizio e alla fine delle tue funzioni, e ti permetterebbe di rompere, ecc. Ho rimosso alcuni dei comandi ma puoi vedere che questo può essere fatto estensivo quanto ne hai bisogno.

PAUSE_NOW  = thread.allocate_lock() 
def pause(s): 
''' 
    FUNCTION: testStatus 

    DESCRIPTION: function passed to all test objects 

    INPUTS: none 

    RETURNS: none 
''' 
    global Pause_NOW 
    PAUSE_NOW.acquire() 
    time.sleep(s) 
    PAUSE_NOW.release() 

`

def server(): 
    ''' 
     \r\n 
     FUNCTION: server 

     DESCRIPTION: UDP server that launches a UDP client. The client it 
        starts can issue commands defined in cmdlineop. Most 
        functions return a status, but some are meant to block 
        the main thread as a means of pausing a test, in which case 
        a default response is returned. 

     INPUTS: none 

     RETURNS: none 
    ''' 
    global EXIT 
    global Pause_NOW 

    host = "localhost" 
    port = 21567 
    buf = 1024 
    addr = (host,port) 

    UDPSock = socket(AF_INET,SOCK_DGRAM) 
    UDPSock.bind(addr) 
    sleep(1) 
    os.startfile('client.py') 
    #os.system('start python client.py') 
    cmdlineop = { 
        'pausenow' : "PAUSE_NOW.acquire()", 
        'playnow' : "PAUSE_NOW.release()", 
       } 
    while 1: 
     output = 'RECEIVED CMD' 
     # if EXIT: break 
     data,addr = UDPSock.recvfrom(buf) 
     if not data: 
      break 
     else: 
      if cmdlineop.has_key(data.split()[0]): 
       exec(cmdlineop[(data.split()[0])]) 
       UDPSock.sendto(('\n'+output+'\n'),addr) 
       data = '' 
      else: 
       UDPSock.sendto('INVALID CMD',addr) 
    UDPSock.close() 
+0

Non capisco appieno ciò che il primo responsabile ha fatto con questo client/server UDP. PyDev non funziona perché riceve questi strani errori con un file XML che il debugger tenta di scrivere con informazioni di stato. Forse ha più thread che tentano di scrivere sul file nello stesso momento quando esegue un programma multithread e non è impostato per gestirlo. – MMM

+0

scusa, mai usato pyDev – pyInTheSky

Problemi correlati