Sembra proprio che Ruby 2.0 non avrà nè continuations nè green threads.
Sulle continuazioni non mi pronuncio (se c’è la possibilità di
manipolare lo stack di attivazione dei metodi dal codice Ruby, allora è
possibile implementare le continuazioni senza dover toccare la VM).
Ma il passaggio ai thread nativi mi sembra un errore: quali sono i
vantaggi dell’abbandonare un modello di threading uniforme che tra
l’altro permette cose che i modelli nativi non offrono?
Non sarebbe meglio tenere i green threads ed supportare i thread nativi
tramite una libreria?
Sembra proprio che Ruby 2.0 non avrà nè continuations nè green threads.
Sulle continuazioni non mi pronuncio (se c’è la possibilità di
manipolare lo stack di attivazione dei metodi dal codice Ruby, allora è
possibile implementare le continuazioni senza dover toccare la VM).
Ma il passaggio ai thread nativi mi sembra un errore: quali sono i
vantaggi dell’abbandonare un modello di threading uniforme che tra
l’altro permette cose che i modelli nativi non offrono?
Un vantaggio è che se usi i thread nativi, e hai due CPU, un
programma può eseguire due thread in effettivo parallellismo. Questo
può essere utile per applicazioni che devono fare calcoli. Se invece
usi i thread in user space, il sistema operativo ti “vede” come un
singolo thread/processo e quindi non può allocarti più di una CPU per
volta.
Non sarebbe meglio tenere i green threads ed supportare i thread nativi
tramite una libreria?
Semmai sarebbe possibile il contrario… se vuoi usare i thread nativi
l’unica è supportarli direttamente nell’interprete, per come la
capisco io.
Sembra proprio che Ruby 2.0 non avrà nè continuations nè green threads.
Sulle continuazioni non mi pronuncio (se c’è la possibilità di
manipolare lo stack di attivazione dei metodi dal codice Ruby, allora è
possibile implementare le continuazioni senza dover toccare la VM).
Ma il passaggio ai thread nativi mi sembra un errore: quali sono i
vantaggi dell’abbandonare un modello di threading uniforme che tra
l’altro permette cose che i modelli nativi non offrono?
Il pick-axe 1 dice, a proposito dei green threads:
you don’t get certain benefits from having native threads. You may
experience thread
starvation (that’s where a low-priority thread doesn’t get a chance
to run). If you manage to
get your threads deadlocked, the whole process may grind to a halt.
(mentre con i thread nativi, se due thread sono in deadlock gli altri
thread del tuo processo possono proseguire)
And if some thread happens to make a call to the operating system
that takes a long
time to complete, all threads will hang until the interpreter gets
control back.
(Perché il s.o. non “sa” che il tuo processo contiene diversi
“thread”, e se uno dei tuoi thread fa una chiamata bloccante, tipo
leggere o scrivere su una socket, non ha nessuna maniera di dare il
controllo a un altro green thread. Per questo motivo non è pratico
implementare un webserver multithreaded in Ruby.)
l’altro permette cose che i modelli nativi non offrono?
Un vantaggio è che se usi i thread nativi, e hai due CPU, un
programma può eseguire due thread in effettivo parallellismo. Questo
può essere utile per applicazioni che devono fare calcoli. Se invece
usi i thread in user space, il sistema operativo ti “vede” come un
singolo thread/processo e quindi non può allocarti più di una CPU per
volta.
Questo può giustificare avere dei thread interni alla VM, ma non il
fatto di esporli a livello di linguaggio.
Perchè no? Se scrivo un’applicazione grafica, ad esempio, perché mi
vuoi impedire di usare i thread nativi per parallelizzare
l’applicazione di un filtro ai punti di un immagine?
Se proprio si vogliono i thread nativi, non si potrebbe usare un modello
misto e mappare i thread green sui nativi (dove i nativi sono in numero
pari al numero di CPU)?
E’ possibile. Ma ancora, non so perché bisogni per forza limitare il
numero di thread nativi al numero di CPU. Uno dei punti di forza dei
thread nativi è che possono bloccarsi in attesa di I/O senza bloccare
il resto dell’applicazione. In un web server, ad esempio, posso avere
centinaia di thread bloccati in attesa di I/O, anche se ho una sola
CPU.
Il giorno gio, 26/10/2006 alle 16.09 +0200, Matteo V. ha scritto:
l’altro permette cose che i modelli nativi non offrono?
Un vantaggio è che se usi i thread nativi, e hai due CPU, un
programma può eseguire due thread in effettivo parallellismo. Questo
può essere utile per applicazioni che devono fare calcoli. Se invece
usi i thread in user space, il sistema operativo ti “vede” come un
singolo thread/processo e quindi non può allocarti più di una CPU per
volta.
Questo può giustificare avere dei thread interni alla VM, ma non il
fatto di esporli a livello di linguaggio.
Se proprio si vogliono i thread nativi, non si potrebbe usare un modello
misto e mappare i thread green sui nativi (dove i nativi sono in numero
pari al numero di CPU)?
Beh, non è che voglio impedire alcunchè. E’ che non vedo come tutti
questi requisiti implichino a priori l’uso di thread nativi.
Se proprio si vogliono i thread nativi, non si potrebbe usare un modello
misto e mappare i thread green sui nativi (dove i nativi sono in numero
pari al numero di CPU)?
In questo esmpio mi rifacevo al caso della JVM JRockIt di Bea, che è
appunto passata da un modello “solo thread nativi” ad un modello misto
proprio per incrementare le prestazioni lato server.
fatto di esporli a livello di linguaggio.
pari al numero di CPU)?
Sì, è vero che i thread in user-space sono più efficienti! Costa
molto di meno crearli, distruggerli e schedularli, perché posso fare
tutte queste operazioni senza coinvolgere il kernel. Restano però due
problemi:
a) come sfruttare più di una CPU, se disponibile: se non ho i thread
nativi l’unica possibilità è lanciare più processi.
b) come evitare che una chiamata bloccante in un thread blocchi tutto
il processo.
Mentre a) ha una soluzione relativamente semplice, b) non ce l’ha.
Non so come faccia Erlang; tiro a indovinare: in Erlang non puoi
chiamare direttamente il sistema operativo; tutte le operazioni di I/O
sono filtrate da uno strato che le fa vedere come bloccanti al
programmatore Erlang, ma asincrone al sistema operativo.
Insomma, per chi scrive l’interprete Ruby allora le scelte sono due: o
impedisci di fare chiamate dirette (rinunciando a chiamate come a
IO::select) oppure le riscrivi facendole apparire non-bloccanti al
s.o. e bloccanti al programmatore ruby.
Il giorno ven, 27/10/2006 alle 20.31 +0200, chiaro scuro ha scritto:
mi colpisce in questo thread che nessuno si lamenti della mancanza delle
continuation
Heh. Io ne ho parlato però:
Sulle continuazioni non mi pronuncio (se c’è la possibilità di
manipolare lo stack di attivazione dei metodi dal codice Ruby, allora è
possibile implementare le continuazioni senza dover toccare la VM).
mi colpisce in questo thread che nessuno si lamenti della mancanza delle
continuation
Sono abbastanza nuovo a Ruby, ma… non ho avuto ancora la necessita`
di usarle. Qualcuno le ha usate? In che contesto?
Io non le so usare. Cerco di usare sempre gli idiom più semplici, e
le continuation mi sembrano “complicate”. So che ci sono framework
tipo seaside che si basano proprio sulle continuation. Magari se uno
ci fa l’abitudine diventano naturali… Ma non ne sento proprio la
necessità.
M
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
