[Python] threads

[Pietro Battiston]

Il giorno mar, 01/12/2009 alle 18.47 +0100, Enrico Franchi ha scritto:
> On Dec 1, 2009, at 6:26 PM, Pietro Battiston wrote:
> > Uhm... non riesco a seguirti. Poniamo che consideriamo "problema" il
> > fatto di non poter sfruttare efficacemente due processori (senza creare
> > due diversi processi). Allora se Jython, come mi sembra di capire, lo
> > fa, ed esegue sempre codice Python, in cosa è poco intuitivo?
> 
> Perchè Jython ha come primitive quelle della JVM e tutto può funzionare
> come in Java (ovvero ugualmente male o bene che con Java).
> In particolare ti trovi pure quell'obrobrio di synchronized. Se come
> van Roy e Haridi ritieni questo "funzionare male" (e mi associo) allora
> funzioni male come la JVM. Se come Gosling lo consideri funzionare bene,
> allora funziona bene. Suppongo che chi volesse usare il modello di 
> concorrenza di Java lo considererebbe funzionare bene.
> 
> Il GIL impedisce che due thread siano vivi nell'interprete Python. In
> particolare tu assumi che un sacco di cose in Python siano atomiche.
> Senza GIL non lo sarebbero e di conseguenza avresti programmi *scorretti*.
> Jython si appoggia ad una diversa macchina virtuale e di conseguenza
> usa una differente implementazione. Idem IronPython. Idem dovrebbe
> fare Unladen Swallow nel futuro.
> 
> La cosa poco intuitiva sarebbe che il codice Python *corretto* che girasse
> su un cPython senza GIL diventerebbe magicamente scorretto, perchè 
> ti entrerebbero dalla finestra race conditions e altre schifezze ad un
> livello *sottostante* il tuo codice.

Davo per scontato che scrivere "codice per cPython" invece che
semplicemente "codice Python" fosse caldamente sconsigliato...
sbagliavo?

Ovvero: quando gli sviluppatori di Jython dicono "Jython 2.5 implements
the same language as CPython 2.5", mentono o è semplicemente ritenuto
normale che non tutti i programmi in Python x.y funzionino su tutti gli
interpreti di Python x.y?

(ovviamente tutto ciò a prescindere dalle estensioni in C)

Pietro