[Python] weakref ... troppo deboli!...

Alessandro Dentella sandro a e-den.it
Ven 28 Maggio 2010 13:39:43 CEST


Grazie Marco per la dritta, 

On Fri, May 28, 2010 at 12:19:12PM +0200, Marco Giusti wrote:
> On Fri, May 28, 2010 at 10:25:51AM +0200, Alessandro Dentella wrote:
> > Ciao a tutti,
> [...]
> > Quando la finestra risulta incancellabile tramite il bottone kill, anche la
> > cancellazione tramite window-manager fallisce (AttributeError: G objectc has
> > no attribute 'title'). È come se la istanza 'g' sia stata resa monca nonostante
> > esista ancora una finestra con una callback attiva che referenzia (in senso
> > forte) l'istanza stessa ed il suo metodo 'delete_event_cb'. Chiamo 'monca'
> > questa istanza nel senso che:
> > 
> >   * la weakref non la vede più
> >   * la callback capisce che è una istanza di 'G' ma non ne vede l'attributo
> >     di istanza 'title'::
> > 
> >       Traceback (most recent call last):
> > 	File "testd2_win.py", line 39, in clicked_cb
> > 	  if self.title:
> >       AttributeError: 'G' object has no attribute 'title'
> >   
> > Conto su un vostro input per non andare in corto...
> 
> Vediamo un po' tutti i possibili problemi che possono sorgere:
> 
> 1. il metodo `delete_event_cb` elimina il riferimento alla finestra ma
> il metodo può essere ancora chiamato dal padre e non essendoci più
> riferimenti a `self.w`...

non mi è chiaro, il padre sarebbe l'istanza stessa? Eliminata 'w', che
tramite le callback aveva riferimenti (forti, direi) a 'g', g dovrebbe
sparire per me...

Vedo che la grossa differenza fra la mia e la tua versione è nel fatto che io
ho una connect a 'delete_event' che tu non hai, entrambe però eliminiamo con
una chiamata diretta a destroy() la finestra, che quindi emette un
'delete_event'. Quindi io passo due volte dal metodo 'delete_event_cb', la
seconda volta il metodo non ha più self.w... ho capito!

Probabimente la dipendenza dal numero di finestre create è poi dovuta a
ritardi di gtk che è alle prese con il rendering delle finestre. La 10.04
era simulata in VirtualBox quindi più lenta e quindi mi dava l'errore già a
3/4 finestre.

> 2. gli unici riferimenti che hai agli oggetti `G` sono dei riferimenti
> deboli. a questo punto credo che tu debba andare a vedere come i
> riferimenti deboli siano implementati in pygtk. non sono molto preparato
> qui ma sicuramente il problema è questo. Accanto a `self.windows`
> affianca un'altra lista: `self.objects` con riferimenti forti, vedrai
> che a questo punti non hai più di questi problemi.
> 
> per quanto ne so' la gestione dei riferimenti in pygtk è pensata per, ad
> eccezione di casi particolari, potersene dimenticare. nel momento in cui
> non ci sono più riferimenti python ad un oggetto gobject, questo viene
> deallocato.

Il tutto è nato proprio perché vedo crescere a dismisura l'occupazione di
ram in una applicazione GTK e sto pensando di rimpiazzare riferimenti forti
con riferimenti deboli. Questo test era nato proprio dall'esigenza di
vedere se riuscivo a tenere la RAM sotto controllo.

promesso che apro altre discussioni per la ram...

> ps. ti allego la versione modificata.
> 
> pps. la gerarchia che crei è con soli due livelli, perché allora non usi
> due classi distinte? ti allego la versione modificata

Perché nell'esempio reale alcune istanze della classe Mask gemmano altre
istanze della classe Mask, poi nell'esempio ho cambiato il look solo perché
non fosse troppo fuorviante vedere interfacce uguali.

grazie
sandro
*:-)


-- 
Sandro Dentella  *:-)
http://sqlkit.argolinux.org        SQLkit home page - PyGTK/python/sqlalchemy


Maggiori informazioni sulla lista Python