Newsgroup: it.comp.os.linux.development
Titolo: creazione di migliaia di file temporanei

salve a tutti,
mi trovo nella necessità di dover creare un gran numero di file
temporanei, delle dimensioni di pochi bytes (fino ad un massimo di 3 o
4 kbytes), che vengono letti da un sotto processo e subito cancellati
dopo l'uso (spesso poche frazioni di secondo dopo la loro creazione).
in alcuni casi, possono essere anche svariate migliaia.
Ho inizialmente stabilito di crearli nella drectory corrente, ma la
scelta si è dimostrata piuttosto inefficiente: molto spesso questo
codice gira su directory AFS dove chiaramente la creazione e la
cancellazione di svariate migliaia di files è molto inefficiente.
Che soluzione mi consigliereste?
/tmp
/dev/shm
oppure usare delle fifo?
Oppure esiste una soluzione migliore e più adatta?
Grazie per il vostro aiuto!
Andrea

 Che soluzione mi consigliereste?
io cambierei ipc. la soluzione è difficile da suggerire perché non si sa
nulla del programma. vuoi dirci qualcosa in più?

 Che soluzione mi consigliereste?
Cambiare strategia, in genere usare un file per pasare messaggi non è
una buona idea, ma non sapendo nulla di cosa vuoi fare non ti si può
dire di più.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

Dunque, si tratta di un codice di simulazione (fisica) basato su un
interprete Tcl/Tk (la scelta di questo linguaggio non e` stata mia.
non biasimatemi!).
Recentemente, per estenderne le capacita` e semplificarne
l'interfaccia utente (Tcl/Tk non e` certo il linguaggio piu` adatto
per calcoli scientifici), io ho aggiunto un "embedding" di octave.
Ovvero, il core e l'interfaccia rimane basato su Tcl/Tk (abbiamo
decine e decine di script gia` scritti e funzionanti), ma io ho
aggiunto il comando Octave {} che, appunto, accetta comandi di octave.
Per esempio, ora si puo` fare qualcosa come :
# siamo in Tcl
for {set i 0 } {$i < 10 } {incr i} {
  Octave {
    #siamo in octave
    fai_qualcosa_con_octave($i);
  }
  puts "continua in Tcl"
}
per dare un'idea.
Ora, l'embedding di octave in un programma C++ a sua volta embedded
nel Tcl/Tk non e` la cosa piu` immediata... la soluzione migliore che
ho trovato per effettuarlo in modo "rientrante" e pulito e` stato :
1) inizializzo l'interprete di octave e lo tengo li`, in attesa
2) ogni vota che incontro un comando Octave {} :
2.1) processo il suo contenuto per risolvere le variabili Tcl in esso
contenute (tipo la $i dell'esempio) - una roba tipo preprocessore
2.2) salvo su disco il risultato di questo preprocessing in uno
scriptino octave come file temporaneo -diciamo- temp-file.m
2.3) chiedo ad octave di eseguire il comando "source temp-file.m"
2.4) cancello temp-file.m
3) restituisco il controllo all'interprete Tcl
Duqnue ecco spiegato cosa faccio...
La particolarita` di questo codice e` che questa sequenza di
operazioni puo` dover essere ripetuta svariate migliaia di volte, con
segmenti di codice octave molto piccoli... dunque questo crea/usa/
cancella diventa veramente il collo di bottiglia, specie -appunto- su
sistemi che girano su AFS (tipo batch system),..
Io non abbandonerei l'idea del preprocessing e del file temporaneo,
perche` funziona bene ed e` rientrante ... considerato anche che
vorrei mettere il meno possibile le mani dentro la liboctave: e` una
libreria molto complicata e non avrei nemmeno il tempo di studiarla a
fondo. Cosi` facendo, lascio a octave il compito di fare il parsing
dello script e di gestirsi come vuole la sua command line.
Spero di essermi spiegato in maniera sufficientemente chiara....
Grazie a tutti!
Andrea


 3) restituisco il controllo all'interprete Tcl
ma una pipe? ci scrivi lě al posto di scrivere nel file.

 ma una pipe? ci scrivi lì al posto di scrivere nel file.
eh, ci ho pensato. in realta` credo di dover usare una fifo piu` che
una pipe, perche` infine ho comunque bisogno di avere un nome di file,
per octave (che esegue lo script tramite il comando " source
'nomefile.m' ").
dunque ieri ho fatto una prova rapida, ma (come temevo) mi si e`
piantato tutto. cerchero` di approfondire il perche` ma ho un'ipotesi:
1) generalmente pipe e fifo vengono usate quando due processi, che
runnano allo stesso tempo, si scambiano dei dati.
2) nel mio caso, invece, devo scrivere scrivere un file, chiuderlo  e
solo allora posso "eseguirlo" (cioe` leggerlo), all'interno dello
stesso processo
3) credo che il meccanismo si blocchi quando il buffer della mia pipe
(o fifo) in scrittura si riempe: perche` in quel momento non c'e`
ancora nessuno, dall'altro capo del "tubo", capace di leggere e di
liberare il buffer...
hmmm questa e` la mia ipotesi... approfondiro`, perche` il effetti per
il momento questi scriptini sono veramente piccoli e dubito possano
intasare questo buffer.
Altra ipotesi e` che octave, nel suo comando "source", non preveda un
accesso "sequenziale" al file processato... e che dunque una fifo (o
pipe che dir si voglia) non sia compatibile con un "acesso casuale" al
file...
mumble mumble...
hmmm... altre idee? (comincio a convicermi che non ce ne siano...)
grazie!
Andrea

 liberare il buffer...
questo con le fifo può accadere.

 questo con le fifo può accadere.
Gia`...
mumble, mumble...
Grazie dell'idea comunque.... se hai altri suggerimenti o commenti...
Ciao, ciao
Andrea

 pilotarlo. (Sono funzioni C++ built-in, non script .m).
mi sto un po' perdendo. Se hai le strutture dati in memoria, perché
scrivi i .m?


Si` effettivamente e` tutto un po' complicato.
Ti spiego: il codice di simulazione e` stato scritto in C++ ed ha
un'interfaccia programmabile in Tcl/Tk, verso gli utenti.
In pratica, tu scrivi uno script di simulazione in Tcl/Tk, lui lo
processa ed esegue e tu analizzi i risultati.
Io ho aggiunto il comando Octave {}, correndandolo delle funzioni di
supporto di cui ho parlato nel messaggio precedente, per fare in modo
che l'utente possa pilotare 'sta simulazione anche tramote Octave...
(che e` infinitamente piu` comodo del Tcl). Dunque, gli script .m da
cui ha avuto origine questa discussione, sono quelli scritti
dall'utente.... (che dunque sono sconosciuti..).
Dunque l'utente pilota il tutto (strutture dati, etc. etc.) tramite
script Tcl/Tk inframezzati a codice Octave.. Si`, e` un po` un
bordello, ma da` molta soddisfazione... ed e` comodissimo (dal punto
di vista dell'utente)!
Ciao,
Andrea

 dello script e di gestirsi come vuole la sua command line.
non puoi usare un pipe allora? o al limite fatti un ramdisk su cui
scrivi i file temporanei.


 scrivi i file temporanei.
Hm. Le pipe, come dicevo in un altro messaggio, credo non facciano al
caso mio. Piuttosto questa ramdisk mi sembra una buona idea.
Come si usa?
Da una rapida ricerca su google ho trovato che bisogna avere un /dev/
ramdisk (o qualcosa del genere) e fare un mount. Spero che la cosa non
richieda i superpoteri di root, perche` sui linux su cui giriamo i
poteri di root sono decisamente inaccessibili...
Chiunque abbia delle indicazioni in piu` e` il benvenuto!
Grazie Micky.
Andrea


 poteri di root sono decisamente inaccessibili...
http://en.wikipedia.org/wiki/TMPFS
devi chiamare mount, quindi o sei root, o usi sudo o trovi il modo di
persuadere i sistemisti a modificare /etc/fstab o
cambi sistemisti ;-)

 cambi sistemisti ;-)
Ahia, temo il peggio... :-)
Ancora una domanda: l'uso impudico del disco /dev/shm, è deprecabile?
(/dev/shm credo proprio sia una ramdisk tale e quale quella che mi
avete suggerito.. )
Sui nostri sistemi (basati su Fedora) l'ho sempre trovato, ma non
credo sia una scelta veramente portabile..

 Ancora una domanda: l'uso impudico del disco /dev/shm, è deprecabile?
boh! credo che rischi solo la fustigazione da parte dei sistemisti.
Se ti tranquillizza, /dev/shm c'è pure su debinan

 Grazie Micky.
Prego, Micky
