Re: [Python] Mettere in pausa gli altri threads

2013-10-10 Per discussione enrico franchi
2013/10/9 Manlio Perillo manlio.peri...@gmail.com


 Il fatto è che i thread sono sempre in gara.


Appunto. Eliminiamo i thread e ci risparmiamo la noia di trovare la
traduzione.
E ci semplifichiamo anche un altro paio di cose.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Luca
 Per caso mi è capitato di pensare un po' al tuo problema e mi sono detto
 che c'è qualcosa che non va'. Tu hai due casi ogni volta che copi un
 file: la destinazione esiste oppure no. Se la destinazione non esiste
 il thread non viene in qual modo influenzato e quindi non c'è necessità
 che si blocchi in attesa di una risposta dell'utente. Mi sbaglio forse?
 Perché in questo caso un lock banale risolve il tuo problema.



 Supponiamo di avere, nell'ordine, queste richieste di copia

 copy a b
 copy c d
 copy e f

 questo significa che la terza operazione, se vuole sovrascrivere f,
blocca tutte le altre anche se non hanno nulla a che fare con f?

Allora

 - Ho una lista di files che viene generata tramite filtri di inclusione
e/o esclusione.
 - Questa lista viene passata al ciclo che esegue la copia file per file.
 - Per ogni file viene lanciato un Thread (con possibilità di limitare il
numero di thread)
 - Durante la copia uno o più o tutti i file possono essere già presenti
nella/e cartella/e di destinazione.
 - In caso venga chiamato con il parametro --overwrite=ASK, lo script, al
PRIMO file esistente che trova deve bloccare tutto quindi:
   1 - Threads già avviati ma che non hanno ancora fatto la verifica di
os.path.exists (in effetti se è il primo gli altri non ci sono ancora
arrivati)
   2 - Ovviamente bloccare eventuali nuovi thread sul nascere.
   3 - Attendere una risposta dall'utente.
   4 - Reimpostare il parametro overwrite *globale*.
   5 - Riprendere da dove si era fermato.

A questo punto l'overwrire non sarà più ASK ma YES o NO, a seconda dei
casi, e i rimanenti thread si comporteranno di conseguenza.

Da notare che l'utilizzo dei thread è più per una questione grafica
(progress bar multiple) che per una questione pratica. E che comunque non
mi pare molto ultile la conferma da parte dell'utente se poi si propaga per
tutti i file, a quel punto chiamare lo script con --overwrite=YES o NO è
più logico. Credo io.

ciao
Luca
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Manlio Perillo

On 09/10/2013 12:02, Luca wrote:

[...]

  - Ho una lista di files che viene generata tramite filtri di
inclusione e/o esclusione.
  - Questa lista viene passata al ciclo che esegue la copia file per file.
  - Per ogni file viene lanciato un Thread (con possibilità di limitare
il numero di thread)
  - Durante la copia uno o più o tutti i file possono essere già
presenti nella/e cartella/e di destinazione.
  - In caso venga chiamato con il parametro --overwrite=ASK, lo script,
al PRIMO file esistente che trova deve bloccare tutto quindi:


Secondo me ti stai complicando la vita, ma di brutto!


1 - Threads già avviati ma che non hanno ancora fatto la verifica di
os.path.exists (in effetti se è il primo gli altri non ci sono ancora
arrivati)
2 - Ovviamente bloccare eventuali nuovi thread sul nascere.


La 2 non ha senso, in un programma normale (ovviamente IMHO).


3 - Attendere una risposta dall'utente.
4 - Reimpostare il parametro overwrite *globale*.
5 - Riprendere da dove si era fermato.

A questo punto l'overwrire non sarà più ASK ma YES o NO, a seconda dei
casi, e i rimanenti thread si comporteranno di conseguenza.



Devi ripensare alla logica del programma.

Una possibilità è avere l'overwrite settato in partenza, tramite opzione.

Un'altra possibilità è di fare quanto segue (non testato):

1) hai un thread pool con cui interagisci tramite queue.
   Purtroppo la libreria standard di Python non ha una thread pool, ma
   solo un process pool.
2) al thread pool **non** passi il path del file, ma il descrittore di
   file, in modo da evitare possibili race conditions (che non so
   tradurre in italiano)
3) in un thread separato (visto che tanto vuoi usare i thread)
   iteri sulla lista di file, e per ciascun file:

 * apri il file di origine (O_RDONLY)
 * apri il file di destinazione, secondo questa modalità:
   - se `overwrite` è true, lo apri in modalità normale
 (O_CREAT | O_WRONLY)
   - se `overwrite` è false, lo apri i modalità esclusiva
 (O_CREAT | O_EXCL | O_WRONLY) e se fallisce salti la copia
   - se `overwirite` è ask, apri il file in modalità esclusiva,
 e se fallisce chiedi se sovrascrivere il file o meno, e lo
 riapri di conseguenza secondo i punti precedenti
 (O_CREAT | O_WRONLY, oppure O_CREAT | O_EXCL | O_WRONLY)
 * passi i due descrittori di file al thred pool
 * se il pool è pieno, l'operazione precedente (queue.put)
   bloccherà fino a quando non si libera uno slot, quindi non devi
   preoccuparti di cose strane, come bloccare nuovi thread sul
   nascere

   Nota che volendo, puoi aprire il file di origine nel thread pool.

 [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Nicola Larosa
Manlio Perillo wrote:
 race conditions (che non so tradurre in italiano)

Come sarebbe, non lo sai?

Condizioni di razza, no?

Sporconegro, musogiallo, pellerossa, gentleman, quelle cose lì.

-- 
Nicola Larosa - http://www.tekNico.net/

So what if we've been scammed and cheated? Is that going to stop you
from experiencing the good things in life? Is watching a bad movie
going to stop me from watching a good one? So what if you've been
humiliated. Welcome to the club. Is that going to stop you
from experiencing joy and love? - Per Bristow, May 2013

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Marco Beri
2013/10/9 Manlio Perillo manlio.peri...@gmail.com

 race conditions (che non so tradurre in italiano)


Io proverei con situazione di competizione (sottinteso: tra diversi
eventi che vogliono modificare la/accedere alla stessa risorsa).

Ma fa schifo.

Lascia race conditions :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Manlio Perillo

On 09/10/2013 12:57, Marco Beri wrote:

2013/10/9 Manlio Perillo manlio.peri...@gmail.com
mailto:manlio.peri...@gmail.com

race conditions (che non so tradurre in italiano)


Io proverei con situazione di competizione (sottinteso: tra diversi
eventi che vogliono modificare la/accedere alla stessa risorsa).



In generale tendo ad usare termini italiani, quando c'è una traduzione 
ben accettata.  Mi da fastidio quando la gente usa termini inglesi a 
sproposito.



Ma fa schifo.

Lascia race conditions :-)



Se fosse una sola parola sarebbe accettabile, ma due parole inglesi in 
un contesto in lingua italiana è altrettanto brutto.



Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Manlio Perillo

On 09/10/2013 14:55, Daniele Varrazzo wrote:

On 2013-10-09 12:46, Manlio Perillo wrote:

On 09/10/2013 12:57, Marco Beri wrote:



Lascia race conditions :-)



Se fosse una sola parola sarebbe accettabile, ma due parole inglesi
in un contesto in lingua italiana è altrettanto brutto.


https://it.wikipedia.org/wiki/Race_condition



Si, avevo visto anche io.
Sarei curioso di capire l'origine del termine; ma se è come per bug non 
c'è via di uscita...



Non vedo alternative di uso corrente (I don't see alternatives of
electric usage).




Io propongo condizione brutta brutta brutta.
Se gli inglesi/americani sono creativi, perchè non dovremmo esserlo pure 
noi?





Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione m

* Manlio Perillo (manlio.peri...@gmail.com) [131009 15:19]:


Non vedo alternative di uso corrente (I don't see alternatives of
electric usage).


Race condition non è nemmeno presente nel Jargon file...



io lo avevo aggiunto, ma so per certo che nel mentre anche ESR stava
modificando il file ...

--
 .*.finelli
 /V\
(/ \) --
(   )   Linux: Friends dont let friends use Piccolosoffice
^^-^^ --

Non saprei spiegare il perché della paura per gli OGM. E' difficile dire
come nasca la paura e come si può bloccare il timore di qualcosa che non
si conosce. E' una forma di superstizione e va combattuta come tutte le
cose inesistenti che possono essere più pericolose di quelle esistenti.

   Rita Levi Montalcini
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Daniele Varrazzo

On 2013-10-09 14:09, Manlio Perillo wrote:

On 09/10/2013 14:55, Daniele Varrazzo wrote:

On 2013-10-09 12:46, Manlio Perillo wrote:

On 09/10/2013 12:57, Marco Beri wrote:



Lascia race conditions :-)



Se fosse una sola parola sarebbe accettabile, ma due parole inglesi
in un contesto in lingua italiana è altrettanto brutto.


https://it.wikipedia.org/wiki/Race_condition



Si, avevo visto anche io.
Sarei curioso di capire l'origine del termine; ma se è come per bug
non c'è via di uscita...


Praticamente tutte le altre lingue hanno una traduzione locale, ma 
usano anche una parola locale per dire computer (ordinateur, 
computadora, wikipedia suggerisce anche ordenadôr in friulano). In 
italiano calcolatore o elaboratore non vanno per la maggiore 
(neanche in napoletano, sempre stando a wikipedia).



Io propongo condizione brutta brutta brutta.
Se gli inglesi/americani sono creativi, perchè non dovremmo esserlo 
pure noi?


Situazione di competizione è quasi un endecasillabo. Fosse per me 
direi che i thread sono in gara, ma intendo solo per capirmi tra me e 
me, non per provare a far capire ad altri (Piro: Questi thread sono in 
gara. Altri: Cosa? Piro: C'è una race condition. Altri: aaahh.)


Questo insetto è causato da una gara tra fili...


--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-09 Per discussione Manlio Perillo

On 09/10/2013 15:32, Daniele Varrazzo wrote:

[...]
Situazione di competizione è quasi un endecasillabo. Fosse per me
direi che i thread sono in gara, ma intendo solo per capirmi tra me e
me, non per provare a far capire ad altri (Piro: Questi thread sono in
gara. Altri: Cosa? Piro: C'è una race condition. Altri: aaahh.)



Il fatto è che i thread sono sempre in gara.


Questo insetto è causato da una gara tra fili...



Nel Jargon File c'è una discussione surreale sui bug

There is a bug in this ant farm!
What do you mean? I don't see any ants in it.
That's the bug.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-08 Per discussione Luca
Il giorno 04 ottobre 2013 19:02, Marco Giusti marco.giu...@gmail.com ha
scritto:



 Ti allego un esempio con il lock preso qui[1].

 Ciao
 Marco

 [1]
 http://code.activestate.com/recipes/577803-reader-writer-lock-with-priority-for-writers/

 Ottimo! è esattamente ciò che mi serviva.

L'ho adattato un pochino al mio codice e si comporta esattamente come
volevo.

Ancora grazie mille.
ciao
Luca.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-08 Per discussione Marco Giusti
On Tue, Oct 08, 2013 at 08:52:30AM +0200, Luca wrote:
 Il giorno 04 ottobre 2013 19:02, Marco Giusti marco.giu...@gmail.com ha
 scritto:
 
 
 
  Ti allego un esempio con il lock preso qui[1].
 
  Ciao
  Marco
 
  [1]
  http://code.activestate.com/recipes/577803-reader-writer-lock-with-priority-for-writers/
 
 Ottimo! è esattamente ciò che mi serviva.
 
 L'ho adattato un pochino al mio codice e si comporta esattamente come
 volevo.

Per caso mi è capitato di pensare un po' al tuo problema e mi sono detto
che c'è qualcosa che non va'. Tu hai due casi ogni volta che copi un
file: la destinazione esiste oppure no. Se la destinazione non esiste 
il thread non viene in qual modo influenzato e quindi non c'è necessità
che si blocchi in attesa di una risposta dell'utente. Mi sbaglio forse?
Perché in questo caso un lock banale risolve il tuo problema.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-08 Per discussione Manlio Perillo

On 04/10/2013 19:02, Marco Giusti wrote:

[...]
Senza (troppo) leggere il tuo codice, concettualmente allora è come
avevo descritto nella mia prima email. Supponi che hai i due lock come
ti avevo descritto, il worker si comporta più o meno così:

def worker():
while True:
path = q.get()
if os.path.exists(path) and override is ASK:
with w:
global override
override = ask_dialog()
with r:
copy(path)
q.task_done()

questo è a larghe spanne quello che dovrebbe fare. I due lock sono
speciali. r lo puoi acquisire solo se nessuno reclama w. w lo puoi
acquisire solo se nessuno ha acquisito r. Così se due operazioni di
copia sono in atto e una terza vuole sovrascrivere un file, la terza si
blocca fintanto che le due precedenti non sono completate. Nuove
operazioni di copia sono bloccate perché qualcuno reclama w. Quando w
viene rilasciato, i worker possono di nuovo acquisire r.



Supponiamo di avere, nell'ordine, queste richieste di copia

copy a b
copy c d
copy e f

questo significa che la terza operazione, se vuole sovrascrivere f, 
blocca tutte le altre anche se non hanno nulla a che fare con f?



Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Carlos Catucci
2013/10/5 Marco De Paoli depao...@gmail.com

 il KR è il libro base per imparare il C.
 http://en.wikipedia.org/wiki/The_C_Programming_Language

 Trattasi del libro scritto da due pilastri dell'informatica coinvolti
 direttamente nello sviluppo di Unix (Ritchie, RIP :-( )
 Insomma, siamo alle basi primordiali di quanto noi oggi chiamiamo
 informatica
 (qualcuno ha detto che senza di loro Steve Jobs sarebbe stato a piantar
 patate)

 Se pensi che l'interprete python è scritto in C e che io stesso sto
 scrivendo questa mail su un ubuntu linux... diciamo che il KR meriterebbe
 letto, se non altro per respirare un po' l'aria che respirarono i Padri
 Fondatori :-)

 (... tra l'altro è scritto molto bene e per imparare veramente il C rimane
 un testo fondamentale)


Mi permetto di sottolineare che il KR e'il manuale per chi sa programmare
in C e vuole capire le raffinatezze del linguaggio. Un neofita ci si perde
dopo poche righe. E rimane una lettura che anche se non scriverai mai una
riga di C merita di essere fatta.

Idem per lo Stroustrup per il C++.

Carlos
-- 
Somos los que amasan, sin embargo no tenemos pan,
somos los que cavan el carbón, sin embargo tenemos frío
somos los que no tienen nada, y estamos viniendo a tomar el mundo.
Tassos Livaditis (Poeta greco, 1922, 1988)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Marco Beri
On 5 Oct 2013 10:44, Carlos Catucci carlos.catu...@gmail.com wrote:

 Mi permetto di sottolineare che il KR e'il manuale per chi sa
programmare in C e vuole capire le raffinatezze del linguaggio. Un neofita
ci si perde dopo poche righe. E rimane una lettura che anche se non
scriverai mai una riga di C merita di essere fatta.

Lo lessi nel 1985, a Sistemi 1 a Milano.
Alla fine della lettura, ricordo bene, pensai Fico! Ho capito tutto, so
programmare in C.

Però ricordo altrettanto bene la frustrazione degli n mila segmentation
fault, core dumped prima di riuscire a far girare il primo programmino di
poche righe.

Infine come dimenticare il senso di profondo esoterismo del primo **p++ che
scrissi...

:-)

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/10/2013 04:09, Marco De Paoli wrote:
 [...] il KR │ il libro base per imparare il C. 
 http://en.wikipedia.org/wiki/The_C_Programming_Language
 
 Trattasi del libro scritto da due pilastri dell'informatica
 coinvolti direttamente nello sviluppo di Unix (Ritchie, RIP :-( ) 
 Insomma, siamo alle basi primordiali di quanto noi oggi chiamiamo 
 informatica (qualcuno ha detto che senza di loro Steve Jobs sarebbe
 stato a piantar patate)
 

Diciamo che *era* il libro base, dato che da allora lo standard si │
evoluto portando diverse cose che migliorano la leggibilit¢ del codice.


 [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlJP3wsACgkQscQJ24LbaUTD4ACaA0Dbg3hV6MOo37+wkpj3kji/
nZgAn1v/0Qk6S9ctdTosX7K7Yll04O+Y
=5C+O
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/10/2013 10:43, Carlos Catucci wrote:
 [...] Mi permetto di sottolineare che il KR e'il manuale per chi
 sa programmare in C e vuole capire le raffinatezze del linguaggio.
 Un neofita ci si perde dopo poche righe. E rimane una lettura che
 anche se non scriverai mai una riga di C merita di essere fatta.
 

No, per quello c'│ lo standard:
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

che consiglio perch│ │ una delle specifiche meglio scritte che abbia
mai letto.

 Idem per lo Stroustrup per il C++.
 

Vade retro.
Il manuale del C++ ha molte pi pagine del KR.

Il KR ha il grandissimo pregio, che │ lo stesso di quello del C, di
essere minimale (ma non banale).


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlJP4HUACgkQscQJ24LbaUQfIQCeL/Huvl07m4eGg1CJ20ffL5Ci
KJMAnRHjCNHGbWOTA8UqHuQTWJotvVMY
=OyWb
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Marco Beri
On 5 Oct 2013 11:48, Manlio Perillo manlio.peri...@gmail.com wrote:

 No, per quello c'│ lo standard:
 http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
 che consiglio perch│ │ una delle specifiche meglio scritte che abbia
 mai letto.

Manlio,
ti consiglio di usare lettera più apostrofo e dimenticarti le lettere
accentate fino a sistemazione del bug.

La tua autorevolezza scema a ogni messaggio con l'encoding scazzato... :-D

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Nicola Larosa
 Manlio Perillo wrote:
 No, per quello c'│ lo standard: 
 http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf che
 consiglio perch│ │ una delle specifiche meglio scritte che abbia
 mai letto.

Marco Beri wrote:
 Manlio, ti consiglio di usare lettera più apostrofo e dimenticarti
 le lettere accentate fino a sistemazione del bug.

Mi associo, è un workaround ragionevole.


 La tua autorevolezza scema a ogni messaggio con l'encoding scazzato...
 :-D

Quello no, però è una discreta rottura di scatole leggerti così.

-- 
Nicola Larosa - http://www.tekNico.net/

Sex that is given against one's will, or as an exchange, is not real sex.
It's a fraction of the joy which real sex can be. And hurting another
is never desirable. Not just because there's invariably a backlash.
Because we're all part of the same One life; because hurting another
is hurting the being we are all part of. - Sophia Gubb, May 2012
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Marco Beri
On 5 Oct 2013 12:32, Nicola Larosa n...@teknico.net wrote:

 Marco Beri wrote:
  La tua autorevolezza scema a ogni messaggio con l'encoding scazzato...

 Quello no, però è una discreta rottura di scatole leggerti così.

Ovviamente la parte dell'autorevolezza era una battuta.

Manlio è una sicurezza.

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Manlio Perillo

On 05/10/2013 13:29, Marco Beri wrote:


On 5 Oct 2013 12:32, Nicola Larosa n...@teknico.net
mailto:n...@teknico.net wrote:

  Marco Beri wrote:
   La tua autorevolezza scema a ogni messaggio con l'encoding scazzato...
 
  Quello no, però è una discreta rottura di scatole leggerti così.

Ovviamente la parte dell'autorevolezza era una battuta.

Manlio è una sicurezza.



Troppo gentile.

Per la cronaca, la causa sembra essere Enigmail, non Thunderbird.
L'ho disabilitato.

Il bug dovrebbe essere:
http://sourceforge.net/p/enigmail/bugs/106/

dicono di averlo risolto, ma non è così; e dai commenti nel bug tracker 
gli sviluppatori non mi ispirano molta fiducia...


Ho provato a leggere i sorgenti, ma quella non è roba pensata per essere 
letta e capita da un essere umano normale.






Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Carlos Catucci
2013/10/5 Manlio Perillo manlio.peri...@gmail.com

 Vade retro.
 Il manuale del C++ ha molte pi pagine del KR.

 Il KR ha il grandissimo pregio, che │ lo stesso di quello del C, di
 essere minimale (ma non banale).


Io mi riferivo al fatto che se sei un niubbo col cazzo che ci salti fuori.
E chiedo scusa per il francese.

Carlos
-- 
Somos los que amasan, sin embargo no tenemos pan,
somos los que cavan el carbón, sin embargo tenemos frío
somos los que no tienen nada, y estamos viniendo a tomar el mundo.
Tassos Livaditis (Poeta greco, 1922, 1988)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-05 Per discussione Manlio Perillo

On 05/10/2013 14:56, Carlos Catucci wrote:


2013/10/5 Manlio Perillo manlio.peri...@gmail.com
mailto:manlio.peri...@gmail.com

Vade retro.
Il manuale del C++ ha molte pi pagine del KR.

Il KR ha il grandissimo pregio, che │ lo stesso di quello del C, di
essere minimale (ma non banale).


Io mi riferivo al fatto che se sei un niubbo col cazzo che ci salti
fuori. E chiedo scusa per il francese.



Non condivido.
Se sei un niubbo hai problemi anche in Python.

 [...]


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Luca
Il giorno 03 ottobre 2013 18:11, Marco Giusti marco.giu...@gmail.com ha
scritto:


 Ogni thread effettua un'operazione in concomitanza con gli altri. Nel
 momento in cui si ha una sovrascrizione ottiene un lock esclusivo. Tutti
 gli altri thread finiscono le loro operazioni ma nuovi thread non
 possono iniziarne di nuove.

 Questo è all'incirca quello che volevi?


Circa. Non solo non devono inziare nuove operazioni, ma quelle attuali
dovrebbero esser messe in pausa e, quando riprendono, tenere in
considerazione la risposta la dialogo di conferma.
Una cosa del tipo:

global_event = queue.get()
global_event.wait()
overwrite = queue.get()
if os.path.exits(filename) == False or overwrite == True:
 ... etc etc...

ciao
Luca
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Giusti
On Fri, Oct 04, 2013 at 02:47:23PM +0200, Luca wrote:
 Il giorno 03 ottobre 2013 18:11, Marco Giusti marco.giu...@gmail.com ha
 scritto:
 
 
  Ogni thread effettua un'operazione in concomitanza con gli altri. Nel
  momento in cui si ha una sovrascrizione ottiene un lock esclusivo. Tutti
  gli altri thread finiscono le loro operazioni ma nuovi thread non
  possono iniziarne di nuove.
 
  Questo è all'incirca quello che volevi?
 
 
 Circa. Non solo non devono inziare nuove operazioni, ma quelle attuali
 dovrebbero esser messe in pausa e, quando riprendono, tenere in
 considerazione la risposta la dialogo di conferma.
 Una cosa del tipo:
 
 global_event = queue.get()
 global_event.wait()
 overwrite = queue.get()
 if os.path.exits(filename) == False or overwrite == True:
  ... etc etc...

Perdonami, puoi spiegarmelo come se avessi cinque anni? Sembra, da come
lo descrivi, che la copia di un file debba essere interrotta a metà per
poi riprendere con una politica differente. Invece il tuo codice sembra
dire il contrario, ovvero una copia deve essere finita sempre con la
politica con cui ha iniziato ma ogni nuova copia deve o aspettare una
risposta o utilizzare la politica selezionata.

PS. quandi effettui test logici è meglio se usi la forma:

if not os.path.exits(filename) or overwrite:

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/10/2013 18:23, Marco Giusti wrote:


asincrono significa, per farla breve:
 -- read ritorna non appena la richiesta viene inoltrata al kernel
 -- poll attende dal kernel che la read è completa

bloccante significa
 -- poll attende dal kernel quando nel buffer interno ci sono dei dati
da leggere
 -- read restituisce solo i dati già nel buffer del kernel, oppure
fallisce se dovrebbe attendere che i dati siano disponibili

Non è proprio così, perchè ad esempio in POSIX AIO vengono usati i
segnali, non poll; ma in Freebsd, ad esempio, kqueue supporta aio
direttamente.




Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlJOyHYACgkQscQJ24LbaUTHqQCggzgp9Oko0CjaplkfgQooGQ1P
a5IAn2Rp8DQAuXznfhZ/zPEd3X1/6awN
=cxHC
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Beri
2013/10/4 Marco Giusti marco.giu...@gmail.com

   if not os.path.exits(filename) or overwrite:


Ma anche a voi non preme mettere le parentesi in questi casi?

  if (not os.path.exits(filename)) or overwrite:

Lo so che il not vince, ma è più forte di me e voglio essere certo, un
domani, di non avere invece inteso:

  if not (os.path.exits(filename) or overwrite):

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Giusti
On Fri, Oct 04, 2013 at 03:53:46PM +0200, Marco Beri wrote:
 2013/10/4 Marco Giusti marco.giu...@gmail.com
 
if not os.path.exits(filename) or overwrite:
 
 
 Ma anche a voi non preme mettere le parentesi in questi casi?
 
   if (not os.path.exits(filename)) or overwrite:
 
 Lo so che il not vince, ma è più forte di me e voglio essere certo, un
 domani, di non avere invece inteso:
 
   if not (os.path.exits(filename) or overwrite):

Ehm, di fatti dopo aver mandato l'email ho controllato per sicurezza ma
ero abbastanza sicuro del risultato :)

Ciao
Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco De Paoli
Il giorno 04 ottobre 2013 15:53, Marco Beri marcob...@gmail.com ha
scritto:

 2013/10/4 Marco Giusti marco.giu...@gmail.com

   if not os.path.exits(filename) or overwrite:


 Ma anche a voi non preme mettere le parentesi in questi casi?


in effetti preme anche a me, ok conoscere tutta le regole di precedenza
degli operatori:ma perché dovrei riprortarle alla working memory e non
poter contare, a colpo d'occhio, sulle parentesi?

... anche perché, data la limitatezza della mia working memory, una volta
soppiantato il contenuto per farci stare le regole di precedenza degli
operatori ... è finita! ... cosa stavo facendo? ... è ora di pausa caffè?
... chi sono?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Beri
2013/10/4 Marco De Paoli depao...@gmail.com

 Il giorno 04 ottobre 2013 15:53, Marco Beri marcob...@gmail.com ha
 scritto:

 2013/10/4 Marco Giusti marco.giu...@gmail.com

   if not os.path.exits(filename) or overwrite:


 Ma anche a voi non preme mettere le parentesi in questi casi?


 in effetti preme anche a me, ok conoscere tutta le regole di precedenza
 degli operatori:ma perché dovrei riprortarle alla working memory e non
 poter contare, a colpo d'occhio, sulle parentesi?... anche perché, data la
 limitatezza della mia working memory, una volta soppiantato il contenuto
 per farci stare le regole di precedenza degli operatori ... è finita! ...
 cosa stavo facendo? ... è ora di pausa caffè? ... chi sono?


Ah, meno male, non sono solo :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Luca
Il giorno 04 ottobre 2013 15:34, Marco Giusti marco.giu...@gmail.com ha
scritto:


 Perdonami, puoi spiegarmelo come se avessi cinque anni? Sembra, da come
 lo descrivi, che la copia di un file debba essere interrotta a metà per
 poi riprendere con una politica differente. Invece il tuo codice sembra
 dire il contrario, ovvero una copia deve essere finita sempre con la
 politica con cui ha iniziato ma ogni nuova copia deve o aspettare una
 risposta o utilizzare la politica selezionata.

 Beh a dire il vero è opinione comunque che io sia un genio ad esporre male
le cose :\

in effetti  è come dici tu. è la nuova copia che parte che deve aspettre
una risposta.
Solo che la verifica vene fatta dentro al worker.

Ti pastobinno la funzione operaia con le modifiche che stavo cercando di
testare sullo script di test.
Magari così capisci meglio che intendo e magari mi indicate altri errori di
concetto.

http://pastebin.com/rFLzW7xy

ciao
Luca
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Luca
if qobj.overwrite is not None:
(UFFA!)


Il giorno 04 ottobre 2013 16:58, Luca luca...@gmail.com ha scritto:

 accidenti !

 overwrite = qobj.overwrite or overwrite
 meglio
 if qobj.overwrite is None:
 overwrite = qobj.overwrite

 vabbeh è un esempio passatemela


 Il giorno 04 ottobre 2013 16:52, Luca luca...@gmail.com ha scritto:

 Il giorno 04 ottobre 2013 15:34, Marco Giusti marco.giu...@gmail.com ha
 scritto:


 Perdonami, puoi spiegarmelo come se avessi cinque anni? Sembra, da come
 lo descrivi, che la copia di un file debba essere interrotta a metà per
 poi riprendere con una politica differente. Invece il tuo codice sembra
 dire il contrario, ovvero una copia deve essere finita sempre con la
 politica con cui ha iniziato ma ogni nuova copia deve o aspettare una
 risposta o utilizzare la politica selezionata.

 Beh a dire il vero è opinione comunque che io sia un genio ad esporre
 male le cose :\

 in effetti  è come dici tu. è la nuova copia che parte che deve aspettre
 una risposta.
 Solo che la verifica vene fatta dentro al worker.

 Ti pastobinno la funzione operaia con le modifiche che stavo cercando di
 testare sullo script di test.
 Magari così capisci meglio che intendo e magari mi indicate altri errori
 di concetto.

 http://pastebin.com/rFLzW7xy

 ciao
 Luca




___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Mariani
La pagina 47 del  KR non si dimentica. Mai.

... ma era poi la 47? o 49?  :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Beri
On Fri, Oct 4, 2013 at 6:40 PM, Marco Mariani bir...@gmail.com wrote:

 La pagina 47 del  KR non si dimentica. Mai.

 ... ma era poi la 47? o 49?  :)


Che ricordi... :-)

Comunque la 47 direi: http://zanasi.chem.unisa.it/download/C.pdf

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco Giusti
On Fri, Oct 04, 2013 at 04:52:40PM +0200, Luca wrote:
 Il giorno 04 ottobre 2013 15:34, Marco Giusti marco.giu...@gmail.com ha
 scritto:
 
 
  Perdonami, puoi spiegarmelo come se avessi cinque anni? Sembra, da come
  lo descrivi, che la copia di un file debba essere interrotta a metà per
  poi riprendere con una politica differente. Invece il tuo codice sembra
  dire il contrario, ovvero una copia deve essere finita sempre con la
  politica con cui ha iniziato ma ogni nuova copia deve o aspettare una
  risposta o utilizzare la politica selezionata.
 
 Beh a dire il vero è opinione comunque che io sia un genio ad esporre male
 le cose :\
 
 in effetti  è come dici tu. è la nuova copia che parte che deve aspettre
 una risposta.
 Solo che la verifica vene fatta dentro al worker.
 
 Ti pastobinno la funzione operaia con le modifiche che stavo cercando di
 testare sullo script di test.
 Magari così capisci meglio che intendo e magari mi indicate altri errori di
 concetto.
 
 http://pastebin.com/rFLzW7xy

Senza (troppo) leggere il tuo codice, concettualmente allora è come
avevo descritto nella mia prima email. Supponi che hai i due lock come
ti avevo descritto, il worker si comporta più o meno così:

def worker():
while True:
path = q.get()
if os.path.exists(path) and override is ASK:
with w:
global override
override = ask_dialog()
with r:
copy(path)
q.task_done()

questo è a larghe spanne quello che dovrebbe fare. I due lock sono
speciali. r lo puoi acquisire solo se nessuno reclama w. w lo puoi
acquisire solo se nessuno ha acquisito r. Così se due operazioni di
copia sono in atto e una terza vuole sovrascrivere un file, la terza si
blocca fintanto che le due precedenti non sono completate. Nuove
operazioni di copia sono bloccate perché qualcuno reclama w. Quando w
viene rilasciato, i worker possono di nuovo acquisire r.

Ti allego un esempio con il lock preso qui[1].

Ciao
Marco

[1] 
http://code.activestate.com/recipes/577803-reader-writer-lock-with-priority-for-writers/
import os
import time
import threading
import Queue


class _LightSwitch:

def __init__(self, lock):
self.__counter = 0
self.__mutex = threading.Lock()
self.__lock = lock

def acquire(self):
self.__mutex.acquire()
self.__counter += 1
if self.__counter == 1:
self.__lock.acquire()
self.__mutex.release()

def release(self):
self.__mutex.acquire()
self.__counter -= 1
if self.__counter == 0:
self.__lock.release()
self.__mutex.release()

def __enter__(self):
return self.acquire()

def __exit__(self, exc_value, exc_type, traceback):
self.release()


def RWLock():
no_readers = threading.Lock()
no_writers = threading.Lock()
readers_queue = threading.Lock()
read_switch = _LightSwitch(no_writers)
write_switch = _LightSwitch(no_readers)

class ReadLock:

def acquire(self):
readers_queue.acquire()
no_readers.acquire()
read_switch.acquire()
no_readers.release()
readers_queue.release()

def release(self):
read_switch.release()

def __enter__(self):
return self.acquire()

def __exit__(self, exc_value, exc_type, traceback):
self.release()

class WriteLock:

def acquire(self):
write_switch.acquire()
no_writers.acquire()

def release(self):
no_writers.release()
write_switch.release()

def __enter__(self):
return self.acquire()

def __exit__(self, exc_value, exc_type, traceback):
self.release()

return ReadLock(), WriteLock()


class Thread(threading.Thread):

def __init__(self, target, *args):
threading.Thread.__init__(self, target=target, args=args)
self.daemon = True
self.start()


ASK = object()
ALWAYS = object()
NEVER = object()
override = ASK


def ask_dialog(path):
ask = None
while ask not in (yes, no, never, always):
print Should I override %s? % path
ask = raw_input(type 'yes', 'no', 'never' or 'always': )
return ask


def copy(path, t):
print copying, path
time.sleep(t)
print finished copying, path


def worker(q, r, w, t):
global override
while True:
path = q.get()
if os.path.exists(path):
with w:
if override is ALWAYS:
pass
elif override is NEVER:
q.task_done()
continue
elif override is ASK:
o = ask_dialog(path)
if o in (no, never):
   

Re: [Python] Mettere in pausa gli altri threads

2013-10-04 Per discussione Marco De Paoli
2013/10/4 Diego Barrera diegonebarr...@yahoo.it

 On 04/10/2013 18:46, Marco Beri wrote:

  On Fri, Oct 4, 2013 at 6:40 PM, Marco Mariani bir...@gmail.com mailto:
 bir...@gmail.com wrote:

 La pagina 47 del  KR non si dimentica. Mai.

 ... ma era poi la 47? o 49?  :)


 Che ricordi... :-)

 Comunque la 47 direi: 
 http://zanasi.chem.unisa.it/**download/C.pdfhttp://zanasi.chem.unisa.it/download/C.pdf

  Cioe'?


il KR è il libro base per imparare il C.
http://en.wikipedia.org/wiki/The_C_Programming_Language

Trattasi del libro scritto da due pilastri dell'informatica coinvolti
direttamente nello sviluppo di Unix (Ritchie, RIP :-( )
Insomma, siamo alle basi primordiali di quanto noi oggi chiamiamo
informatica
(qualcuno ha detto che senza di loro Steve Jobs sarebbe stato a piantar
patate)

Se pensi che l'interprete python è scritto in C e che io stesso sto
scrivendo questa mail su un ubuntu linux... diciamo che il KR meriterebbe
letto, se non altro per respirare un po' l'aria che respirarono i Padri
Fondatori :-)

(... tra l'altro è scritto molto bene e per imparare veramente il C rimane
un testo fondamentale)

Ad ogni modo, anche a me parlando di precedenza degli operatori è subito
venuto alla memoria il Kernighan e Ritchie e il relativo specchietto delle
precedenze degli operatori

Ma che altri due Marco, qui in lista, vadano addirittura a colpi di
citazioni per numero di pagina mi lascia senza parole

Se il KR è a buon diritto il Libro della Genesi per il programmatore,
allora non mi resta che nominare, seduta stante, i due studiosi Beri e
Mariani come filologi biblisti della nostra piccola confraternita

Marco (... eh, sì, un altro Marco ancora)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Fabrizio Mancini
Il giorno 03 ottobre 2013 10:43, Luca luca...@gmail.com ha scritto:

 Qualcuno di voi ha qualche suggerimento ? Qualche direzione da indicarmi?


Uno solo: lascia perdere i thread!
Se devi investire del tempo per studiarti i thread e soprattutto farti
venire i mal di testa per farli funzionare, allora investi il tuo tempo per
studiare soluzioni alternative e più valide.
Una prima che mi viene in mente è la programmazione con eventi deferred,
quali twisted che si integra bene anche con wx da quello che ho visto.
Altrimenti potresti sfruttare il pattern publisher subscriber dove gestisci
tutto tramite un sistema di code.
Almeno questa è la mia esperienza con i thread, e credo anche quella di
qualche altro iscritto alla lista.
HTH
ciao fabrizio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Luca
Hum, non sono molto propenso ad utilizzare twisted, che tra l'altro conosco
a malapena sulla carta.
L'idea del publisher/subscriber, invece, sembra interessante. A dire il
vero stavo già pensando di usare un observer pattern in alternativa.
Mi metterò a studiare :)

*per l'intanto*: grazie Fabrizio.
ciao
Luca


Il giorno 03 ottobre 2013 12:06, Fabrizio Mancini mr.f...@gmail.com ha
scritto:


 Il giorno 03 ottobre 2013 10:43, Luca luca...@gmail.com ha scritto:

 Qualcuno di voi ha qualche suggerimento ? Qualche direzione da indicarmi?


 Uno solo: lascia perdere i thread!
 Se devi investire del tempo per studiarti i thread e soprattutto farti
 venire i mal di testa per farli funzionare, allora investi il tuo tempo per
 studiare soluzioni alternative e più valide.
 Una prima che mi viene in mente è la programmazione con eventi deferred,
 quali twisted che si integra bene anche con wx da quello che ho visto.
 Altrimenti potresti sfruttare il pattern publisher subscriber dove
 gestisci tutto tramite un sistema di code.
 Almeno questa è la mia esperienza con i thread, e credo anche quella di
 qualche altro iscritto alla lista.
 HTH
 ciao fabrizio


 ___
 Python mailing list
 Python@lists.python.it
 http://lists.python.it/mailman/listinfo/python


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Gollum1
Il 03 ottobre 2013 10:43, Luca luca...@gmail.com ha scritto:

 Qualcuno di voi ha qualche suggerimento ? Qualche direzione da indicarmi?

i semafori...

http://www.laurentluce.com/posts/python-threads-synchronization-locks-rlocks-semaphores-conditions-events-and-queues/


-- 
Gollum1
Tesoro, dov'é il mio teoro...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/10/2013 10:43, Luca wrote:
 Salve lista,
 
 Vorrei chiedere consiglio. Sto facendo un programmino che si
 occupa di copiare, cancellare e muovere dei files. Una delle
 opzioni │ quella di copiare *simultaneamente* pi file tramite i
 threads.
 
 Non c'│ nessun problema (a parte forse l'effettiva utilit¢ della 
 cosa)

Perche' ne metti in dubbio l'utilit¢?
La cosa da mettere in dubbio, magari, e' la scelta di usare i threads.

Puoi, infatti, eseguire il comando ``cp`` di sistema con l'opzione
``-i``, usando il modulo subprocess.

 quando l'opzione di sovrascrittura viene decisa a priori. Ma in 
 caso di finestra di dialogo con la domanda Vuoi sovrascrivere? 
 **dovrei sospendere anche gli altri thread, attendere la
 risposta** e poi riprendere il tutto utilizzando quest'ultima per
 decidere il comportamento anche degli altri threads.
 

Perche' mai dovresti eseguire il controllo di esistenza del file di
destinazione all'interno di un thread.
Questa non │ una operazione che prende troppo tempo.  Quello che devi
eseguire in un thread separato e' la copia del file.

Puoi eseguire il controllo in modo semplice nel thread principale,
aprendo il file di destinazione in modalit¢ esclusiva
(O_EXCL, http://docs.python.org/2/library/os.html#open-constants), e
passando poi il descrittore di file al thread pool che si occupa della
copia, utilizzando una queue.

 [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEUEARECAAYFAlJNb8gACgkQscQJ24LbaURq0QCY7YhJWXvdwBQPpfhkBGS/BlQM
PQCfVncP8croKMnRa3rvkxBuWJ/eagU=
=nWro
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/10/2013 12:06, Fabrizio Mancini wrote:
 
 Il giorno 03 ottobre 2013 10:43, Luca luca...@gmail.com 
 mailto:luca...@gmail.com ha scritto:
 
 Qualcuno di voi ha qualche suggerimento ? Qualche direzione da 
 indicarmi?
 
 
 Uno solo: lascia perdere i thread! Se devi investire del tempo per
 studiarti i thread e soprattutto farti venire i mal di testa per
 farli funzionare, allora investi il tuo tempo per studiare
 soluzioni alternative e pi valide. Una prima che mi viene in mente
 │ la programmazione con eventi deferred, quali twisted che si
 integra bene anche con wx da quello che ho visto.

Peccato che con Twisted saresti comunque costretto ad usare i threads...
Gli unici sistemi operativi che supportano l'I/O asincrono
correttamente sono, che io sappia, FreeBSD e Windows.
FreeBSD implementa l'API asincrona POSIX (aio_), mentre Windows l'API
tutta sua.

Il problema │ che, almeno l'ultima volta che avevo visto, Twisted non
supporta queste API.

Attenzione a non confondere l'I/O asincrono con il polling + I/O non
bloccante.


 [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlJNcXEACgkQscQJ24LbaUTW2gCdHSRf1qV6UWByXNWJ7at/oMvL
qXwAoI1m8LchwlATmRsLpL6UxjvzD0fQ
=MhC9
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Luca
Il giorno 03 ottobre 2013 15:23, Manlio Perillo
manlio.peri...@gmail.comha scritto:


 Perche' ne metti in dubbio l'utilit¢?
 La cosa da mettere in dubbio, magari, e' la scelta di usare i threads.

 in effetti era quello il dubbio.


 Puoi, infatti, eseguire il comando ``cp`` di sistema con l'opzione
 ``-i``, usando il modulo subprocess.


Il fatto è che lo script in fase di copia deve avere un'interfaccia grafica
per l'utente finale. E deve essere compilabile con py2exe  per essere
distribuito anche sotto windows.


 Perche' mai dovresti eseguire il controllo di esistenza del file di
 destinazione all'interno di un thread.
 Questa non │ una operazione che prende troppo tempo.  Quello che devi
 eseguire in un thread separato e' la copia del file.

 Puoi eseguire il controllo in modo semplice nel thread principale,
 aprendo il file di destinazione in modalit¢ esclusiva
 (O_EXCL, http://docs.python.org/2/library/os.html#open-constants), e
 passando poi il descrittore di file al thread pool che si occupa della
 copia, utilizzando una queue.


In realtà inizialmente sarebbe dovuto bastare un --overwrite come opzione a
monte. Ma la richiesta è poi stata modificata.
Avevo già pensato di fare il controllo nel thread principale - e l'idea è
ancora valida -, anche se potrebbero essere molti file da controllare
(utilizza walk e una serie di filtri di inclusione ed esclusione per
recuperare i files da copiare).
Il fatto è che mi piaceva l'idea di avere di avere un controllo maggiore
sui thread.

luca
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Luca
2013/10/3 Gollum1 gollum1.smeag...@gmail.com


 i semafori...


 http://www.laurentluce.com/posts/python-threads-synchronization-locks-rlocks-semaphores-conditions-events-and-queues/

 L'avevo trovato proprio questa mattina ma non ho ancora avuto il tempo. Ma
visto che è consigliato darà la precedenza.

Grazie
Luca.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Marco Giusti
On Thu, Oct 03, 2013 at 10:43:48AM +0200, Luca wrote:
 Salve lista,
 
 Vorrei chiedere consiglio.
 Sto facendo un programmino che si occupa di copiare, cancellare e muovere
 dei files.
 Una delle opzioni è quella di copiare *simultaneamente* più file tramite i
 threads.
 
 Non c'è nessun problema (a parte forse l'effettiva utilità della cosa)
 quando l'opzione di sovrascrittura viene decisa a priori. Ma in caso di
 finestra di dialogo con la domanda Vuoi sovrascrivere? **dovrei
 sospendere anche gli altri thread, attendere la risposta** e poi riprendere
 il tutto utilizzando quest'ultima per decidere il comportamento anche degli
 altri threads.

E' un po' il problema degli scrittori e dei lettori (quanto è brutta la
traduzione dall'inglese?). Questo è quello che avviene nei database, tu
vuoi permettere più letture contemporanee ma ogni scrittura deve essere
sequenziale.

Ogni thread effettua un'operazione in concomitanza con gli altri. Nel
momento in cui si ha una sovrascrizione ottiene un lock esclusivo. Tutti
gli altri thread finiscono le loro operazioni ma nuovi thread non
possono iniziarne di nuove.

Questo è all'incirca quello che volevi?

Ciao
Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Marco Giusti
On Thu, Oct 03, 2013 at 03:30:25PM +0200, Manlio Perillo wrote:
 Attenzione a non confondere l'I/O asincrono con il polling + I/O non
 bloccante.

Sono OT ma puoi spegare la differenza tra I/O asincrono e I/O non
bloccante? Per quanto mi ricordo la differenza era: asincrono non hai
risultato e non bloccante non aspetti il risultato.

Forse che la differenza sta' nel fatto che un operazione non-bloccante
fallisce nel momento in cui non può essere completata in maniera
non-bloccante?

Ciao
Marco

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione enrico franchi
2013/10/3 Luca luca...@gmail.com

 2013/10/3 Gollum1 gollum1.smeag...@gmail.com


 i semafori...


 http://www.laurentluce.com/posts/python-threads-synchronization-locks-rlocks-semaphores-conditions-events-and-queues/

 L'avevo trovato proprio questa mattina ma non ho ancora avuto il tempo.
 Ma visto che è consigliato darà la precedenza.



If you've spent years learning tricks to make your multithreaded code work
at all, let alone rapidly, with locks and semaphores and critical sections,
you will be disgusted when you realize it was all for nothing. If there's
one lesson we've learned from 30+ years of concurrent programming, it is: *just
don't share state*. It's like two drunkards trying to share a beer. It
doesn't matter if they're good buddies. Sooner or later, they're going to
get into a fight. And the more drunkards you add to the table, the more
they fight each other over the beer. The tragic majority of MT applications
look like drunken bar fights.

http://zguide.zeromq.org/page:all#Multithreading-with-MQ

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Mettere in pausa gli altri threads

2013-10-03 Per discussione Giampaolo Rodola'
On Thu, Oct 3, 2013 at 7:03 PM, enrico franchi enrico.fran...@gmail.comwrote:




 2013/10/3 Luca luca...@gmail.com

 2013/10/3 Gollum1 gollum1.smeag...@gmail.com


 i semafori...


 http://www.laurentluce.com/posts/python-threads-synchronization-locks-rlocks-semaphores-conditions-events-and-queues/

 L'avevo trovato proprio questa mattina ma non ho ancora avuto il tempo.
 Ma visto che è consigliato darà la precedenza.



 If you've spent years learning tricks to make your multithreaded code work
 at all, let alone rapidly, with locks and semaphores and critical sections,
 you will be disgusted when you realize it was all for nothing. If there's
 one lesson we've learned from 30+ years of concurrent programming, it is:
 *just don't share state*. It's like two drunkards trying to share a beer.
 It doesn't matter if they're good buddies. Sooner or later, they're going
 to get into a fight. And the more drunkards you add to the table, the more
 they fight each other over the beer. The tragic majority of MT applications
 look like drunken bar fights.

 http://zguide.zeromq.org/page:all#Multithreading-with-MQ


Bellissima!


--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python