[Python] Stampare messaggi in finestre differenti..

[Enrico Franchi]

Il giorno 11/ott/08, alle ore 00:02, Pietro Battiston  
<toobaz a email.it> ha scritto:

> Il giorno ven, 10/10/2008 alle 19.33 +0200, Enrico Franchi ha scritto:
>> Il giorno 09/ott/08, alle ore 16:23, MauX <mauro a nonsolocomputer.com>
>> ha scritto:
>>
>>> Il giorno gio, 09/10/2008 alle 15.50 +0200, Leonardo ha scritto:
>>>> contemporaneamente due cicli "infiniti": il gtk.main e il ciclo del
>>>> bot
>>>> che riceve messaggi fino a che non si disconnette..
>>>
>>> beh', i cicli li puoi gestire tranquillamente con i thread, in modo
>>> che
>>> ognuno sia autonomo rispetto all'altro.
>>
>> Non diffondiamo ulteriormente l'aberrazione dei threads nel software
>> applicativo.
>>
>> Il tutto è più efficiente, semplice e scalabile in logica asincro 
>> na.
>
> Pur avendo provato sulla mia pelle quanto la logica asincrona sia più
> comoda e meno prona alla buggosità del threading, mi domando fino a
> quando potremo considerarla più efficiente. Se tra qualche anno i
> processori avranno ancora il clock attuale ma 100 core, sarà ancora
> vero? Lo chiedo perché il trend mi sembra quello.

La prorammazione threaded a memoria condivisa scalerebbe in modo  
scandalosamente atroce su cento cores.

In primo luogo per un numeri così elevato di cores (e nota ché nel  
calcolò scientifico simili cose sono normali), bisogna sostanzialmente  
cambiare l'architettura e passare ad un numa. Cosa ché piano piano  
intel sta facendo. Nel mondo numa pensare di fare threading esplicito  
a memoria condivisa è un buon modo per rendere imbarazzanti le  
performance.

Il threading oggi ha un senso limitato a livello applicativi, IMHO.

>
> (o magari possiamo pensare che saranno le librerie - ad esempio i
> toolkit grafici - che cambieranno drasticamente e diventeranno
> multithreading in modo trasparente per il chiamante?)

Threading "trasparente"? Cosa intendi? Per inciso non credo sia quella  
la direzione versò cui andare. Voglio tutto meno ché race conditions  
e deadlock infilati sotto qualche tonnellata di codice.

Oltretutto le gui funzionano da tempo in logica asincrona. Oggi sempe  
più programmatori stanno capendo che il modello asincrono ha una fila  
lunghissima di vantaggi, che parte dal determinismo e finisce con la  
scalabilità.

Nota, io non sono contro i threads avprescindere. Il problema è quando  
si usa la memoria condivisa nel modello reso popolare da java. Tipo in  
modalita dataflow mi piacciono pure.



>
>
> È solo una curiosità, io non ho i dati per sbilanciarmi
>
> Pietro
>
> _______________________________________________
> Python mailing list
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python