Newsgroup: it.comp.lang.perl
Titolo: Curiosità su Perl 6

Ciao, qualcuno se se il Perl 6 implementerà una forma decente di 
multithreading? Non sono riuscito a trovare nulla in proposito.
Spero non continuino con l'attuale implementazione di (finto) 
multithreading.

Coniglio Sgabbiato wrote:

Prima di provare a risponderti mi sono necessarie un paio di 
precisazioni: perché ritieni che il /multithreading/ di Perl 5.8 sia 
/indecente/ e "finto"?

Emanuele Zeppieri ha scritto:

Perchè copia l'intero processo corrente, con tutto il sovraccarico e la 
lentezza conseguenti, in realtà è una implementazione molto più vicina 
al multiprocessing che al multithreading a memoria condivisa.

Coniglio Sgabbiato wrote:

OK, ma se l'obiezione è questa, non direi che i thread di perl sono
*finti*: al più direi che non sono /lightweight/.
(Confesso che ero convinto che le tue obiezioni fossero diametralmente
opposte, riferite cioè al fatto che si trattasse di thread emulati in 
userspace mediante multitasking cooperativo, che è la cosa a cui
comunemente si allude quando si parla di thread /finti/).
Invece si tratta di *veri* kernel thread, sia su *nix che su Windows
(sebbene quello che dici circa la clonazione incondizionata dei dati sia
corretto).
Però permettimi di fare un paio di precisazioni:
1.
Come già detto si tratta di veri kernel thread che girano tutti nello
stesso processo: quindi *non* c'è istanziazione di nuovi processi.
2.
Altra differenza rispetto ad un'applicazione multiprocesso: è vero che
perdi un po' di tempo (e di spazio) per la creazione dei thread, ma poi
dal punto di vista velocistico ci sono dei vantaggi, perché lo scambio
di dati mediante variabili shared (benché implementato mediante tie su 
variabili effettivamente duplicate), ha latenza più bassa rispetto allo 
scambio di dati tra processi diversi mediante l'usuale sequenza
serializzazione->(pipe|socket)->deserializzazione (od anche mediante
memoria condivisa).
Altro elemento di differenziazione tra processi e thread in perl.
3.
L'overhead per la creazione dei thread è facilmente ammortizzabile: per
il tempo con l'uso di ambienti persistenti o comunque avendo una lunga
durata dei thread, per lo spazio utilizzando pochi thread.
Può sembrare banale, ma quello di pochi thread a lunga durata è il caso
applicativo di gran lunga più frequente e significativo.
Detto tutto questo, in Perl6, o meglio in Parrot, i thread verranno
completamente reimplementati e, da quello che ho capito, ci sarà un tipo
di thread (ne sono previsti 3 diversi tipi) con /vero/ data sharing.
Se vuoi approfondire, segui l'evoluzione di Parrot:
http://www.perlfoundation.org/parrot/index.cgi?publications_on_parrot
(l'implementazione dei thread è descritta in "OnTheArchOfParrotVM.pdf").
Ciao,
Emanuele.

[CUT]

Grazie per la risposta dettagliata, purtroppo a me i thread sarebbero 
serviti per una applicazione che fa uso di thread di breve durata (è 
vero che è un caso meno frequente), nello specifico interrogare in 
parallelo una serie di router. Potrei risolvere mettendo su un servizio 
con thread istanziati allo startup ma non avevo voglia di complicarmi 
troppo la vita	:)
Riguardo ai 3 (!) tipi di thread che saranno presenti in Parrot mi hai 
incuriosito, ho dato una scorsa veloce alla sezione thread del documento 
che mi hai indicato (BTW molto interessante, grazie per la dritta) è 
sono rimasto perplesso, testualmente dicono:
"Each thread has a context, that is, it works with its own stack, its 
own registers, etc. This data is stored in the interpreter structure, so 
it makes sense to have one interpreter around for each thread. So, in 
Parrot, each thread has its own interpreter. *When a new thread is 
created, a whole new interpreter is created* and starts executing the 
subroutine that was assigned the new thread."
Questo significa che in Parrot si avrà lo stesso overhead 
dell'interprete della 5? verrà lanciata una /intera/ nuova istanza della 
VM per ogni thread?

 VM per ogni thread?
PS: per "nuova istanza" non intendo un nuovo processo, ma una copia in 
memoria della VM su un thread diverso dello stesso processo (mi è 
sembrato di capire che funzionerà approssimativamente così).

 I<itself> has to be. It can be shared.
estratto da qui:
http://groups.google.com/group/perl.perl6.internals/msg/4cfb70b0d81dfba
Sono fiducioso, perché uno dei requisiti primari di Parrot è 
l'efficienza :-)
Ciao,
Emanuele.

 
http://groups.google.com/group/perl.perl6.internals/msg/4cfb70b0d81dfba
Anche questo messaggio è interessante:
http://groups.google.com/group/perl.perl6.internals/msg/aa7a13ca8d7f652f
e pure tutto il resto del thread-sui-thread:
http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/4c7de440da84d5c6/04cfb70b0d81dfba?#04cfb70b0d81dfba
-Emanuele

Emanuele Zeppieri ha scritto:
[CUT]
 > Ma questa è la maledizione di "scanner con thread"! ;-)
 >
 > Guarda, per queste applicazioni I/O bound l'approccio più efficiente è
 > quello multitasking cooperativo/event driven (né multithreading né
 > processi multipli).
 >
 > Dà un'occhiata a roba tipo POE, POE::Component::Client::Ping o al
 > semplice Net::Ping: è probabile che già quest'ultimo risolva molti dei
 > tuoi problemi (guarda demo/fping che fa un ping non bloccante su diversi
 > host in parallelo).
 >
 > Alternativamente, potresti usare forks, che implementa i thread (con la
 > stessa identica interfaccia di threads) usando i processi: quindi
 > ottieni simultaneamente il meglio dei due mondi: la semplicità d'uso dei
 > thread e l'efficienza dei processi (su sitemi *nix l'istanziazione di
 > uno nuovo processo è molto efficiente, grazie alla COW).
 >
 > Ma il primo approccio è il migliore in assoluto! ;-)
Avevo provato anche POE, ma è ancora più lento dell'approccio con i 
thread, ci mette comunque troppo a creare gli oggetti. Ho letto la 
pagina CPAN di forks che non conoscevo, sembra interessante e forse può 
effettivamente essere più efficiente, appeno ho tempo lo provo.
[CUT]

Interessante, gli do uno sguardo appena sono un po scarico con il 
lavoro, spero veramente che in Parrot rendano i thread più efficienti, 
perché al momento l'unico linguaggio semi interpretato che ha una 
implementazione ragionevolmente affidabile dei thread è Java, linguaggio 
che sinceramente non trovo piacevolissimo da usare, dovrei costringermi 
a usarlo per un lungo periodo per abituarmi	:)

 a usarlo per un lungo periodo per abituarmi    :)
Io non saprei essere così diplomatico ;-)
Ciao,
Emanuele.

 Io non saprei essere così diplomatico ;-)
e dire che mi dicono sempre che non so essere diplomatico	;)