Otto guru del CLR tengono la sessione su "Designing CLR". Questi signori sono quelli che hanno pensato, progettato, architettato e almeno in parte realizzato il CLR:
Anders Hejlsberg, George Bosworth, James Miller, Jonathan Hawkins, Patrick Dussud, Christopher Brumme, Sean Trowbridge e Brad Abrams. Ecco i nomi illustri che si prestano ad una sessione di domande e risposte con il pubblico presente.
Un paio di giorni fa, incontrando Abrams con Corrado, gli avevo chiesto se avessero intenzione di portare in Longhorn parte del framework in kernel mode. La risposta è stata di no, no per questa release (dubitavate che stessero pensando e progettando per il post-Longhorn?).
Dalle numerose domande sullo stesso tema in questa sessione traspare il fatto che ci stiano già lavorando ma allo stesso tempo che la stabilità viene prima e che probabilmente sarebbe rischioso farlo già da ora.
Avere il garbage collector in kernel mode darebbe, a mio parere, un autentico boost di performance.
Numerose le domande si susseguono su altrettanti argomenti del CLR. Tra le più richieste è quella di poter scaricare dalla memoria assembly e appdomain, questione che porta numerose considerazioni che non la rendono una strada facile da percorrere.
Un'altra questione sollevata è relativa al perchè in c# non venga fatto il controllo se il delegate è null durante l'invocazione di un evento. Forse il problema verrà risolto con un pattern diverso da quello attuale, sta di fatto che già oggi si può facilmente aggirare l'ostacolo come ha suggerito Juwal Lowy al TechEd e che ricordo di avere bloggato.
Non ho potuto fare a meno di sollevare anch'io una domanda a proposito di quanto ho visto nella sessione di C++ a proposito del disposing deterministico degli oggetti. Il team del CLR non è del tutto daccordo che sia veramente deterministica, infatti ci sono dei casi in cui anche dal nuovo C++ non si otterebbe l'effetto voluto. Le slide dell'altra sessione parlavano chiaro ma il discorso qui non è altrettanto ottimistico.
Sollevo allora il classico caso di automazione industriale, dove è necessario avere la certezza di liberare le risorse in determinate condizioni, specie per rispetto di alcune specifiche date da normative di qualità nel mondo automotive.
La risposta è che in realtà stanno realmente pensando a qualcosa di deterministico che però potrebbe avere un impatto disastroso sulle performance, e questo è il motivo per cui ancora non è stato fatto. Ovviamente la soluzione, ribadita dal palco, è quella di usare codice unmanaged C++.
Impressionante e piacevole questa sessione panel dove i relatori si sono mostrati estremamente disponibili e dati al pasto del pubblico con molta modestia.