Garbage collection e programmazione ad eventi: the hard way!

Attenzione, post ad alto delirio computeresco!

Prendiamo un linguaggio garbage collected tipo il C#…. fatto? Fatto!

Ora creiamo una collection di oggetti che per nostra sfortuna devono avere un riferimento al padre… fatto? Fatto!

La memoriziamo nel padre stesso (un bel riferimento circolare insomma)… fatto? Fatto!

Ora creiamo un nuovo event handler e gestiamo una qualche operazione, su un oggetto membro, tenendo traccia dell’avvenuta esecuzione… fatto? Fatto?

Creiamo una nuova collection ma che si riferisce agli stessi oggetti e ripetiamo il riferimento circolare… fatto? Fatto!

Impazziamo per un’intera giornata cercando di risolvere un problema che ha dell’assurdo: sembra che i riferimenti dell’oggetto membro siano duplicati nonostante il contenitore valido sia ovviamente uno ed uno solo quello di cui abbiamo il riferimento… fatto? FATTO!!!!

Più schematico:

  • 2 oggetti gestiscono una collezione ciascuno, il primo è in attesa di distruzione, mentre il secondo è quello “logicamente” valido: l’unico di cui abbiamo ancora un riferimento
  • una serie di oggetti contenuti nelle collezioni gestite da entrambi gli oggetti precedenti e che rilanciano eventi sul loro cambiamento di stato
  • un event handler sempre nel gestore che processa questi cambiamenti, ma ne memorizza il risultato parte in un oggetto membro della gestore stesso, parte nell’oggetto che ha generato l’evento.

Il risultato è un delirio e più o meno si può spiegare così:

  1. oggettino presente nelle 2 collezioni rilancia l’evento “sono cambiato”
  2. il primo gestore gestisce l’evento e memorizza il cambiamento nella sua variabile interna e nell’oggetto che ha generato l’evento stesso (tutto ok, peccato che è il gestore sbagliato)
  3. il secondo gestore gestice l’evento ma trova l’oggetto che lo ha generato come gia’ contrassegnato e non lo memorizza nella sua variabile interna
  4. la classe che coordina il tutto ha un riferimento solo al secondo gestore e trova le informazioni di stato incoerenti fra la variabile membro dello stesso (che di fatto non ha nessun cambiamento memorizzato) e gli oggetti gestiti nella collezione. BUG!

A parte l’inefficienza del tutto causata dal doppio degli eventi gestiti, di cui una volta ad “uffa”, e lo spreco di memoria, il problema non si sarebbe presentato se:

  1. il primo gestore che non ha piu’ nessun riferimento valido (ancora non mi spiego chi lo tiene in vita) fosse stato subito termitato dal garbage collector, ma si sa la vita è dura… la morte è peggio!
  2. l’informazione sullo stato non fosse stata spezzata in 2 parti distinte
    1. una nell’oggetto presente nella collezione e quindi condivisa fra tutte le collezioni
    2. l’altra nel gestore stesso della collezione e quindi privata per ogni collezione

E’ soprattutto quest’ultima parte che avrebbe dovuto farmi riflettere. Quindi mi riprometto che in futuro: non memorizzero’ piu’ lo stato di un operazione in 2 luoghi distinti e soprattutto con uno scope differente nemmeno se minacciato con una pistola alla tempia!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.