Newsgroup: it.comp.os.linux.development
Titolo: Re: OS stile unix: forse un po vecchio ?

> piu' processi.
KJK::Hyperion
 > se la mettiamo così, anche un ponte radio di mezzo metro è IPC.
---------------------------
Renaissance:
 > Infatti... (andiamo avanti)
KJK::Hyperion:
Io ho detto UNIX IPC (in contrapposizione a *POSIX* IPC), non IPC su UNIX
Renaissance:
 > Se hai letto nei link che ho postato, anche la comunicazione in rete
 > e' ipc.
no. Vedi dei PID spuntare dalle funzioni per le socket? vedi un modo
per scambiare file descriptor su una socket? o per impersonare l'user
id del client? Sono IPC solo incidentalmente, e comunque alla lontana.
E in ogni caso non continuerò quella che è solo una discussione sulla
terminologia. La mia era una polemica sterile sull'insolita bruttezza
di un'API UNIX, un'API apparentemente uscita dal nulla, che non ha
niente a che vedere con tutto il resto e contraddice alcuni principi
pressochè universali (come il reference counting delle risorse)
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 ha scritto nel messaggio
news:2huftbF...@uni-berlin.de...

Restando su livelli "scolastici", possiamo tranquillamente affermare che un
processo è un contesto di esecuzione dotato di un proprio spazio di
indirizzamento totalmente separato dal resto dei processi e "virtualmente"
sufficientemente esteso da raggiungere un considerevole quantitativo di
memoria.
Questo significa che ogni processo è un contesto a sé, isolato dagli altri
processi lungo tutto il suo tempo di esecuzione. Ovviamente, riflettendoci
un po' su, un mondo fatto di processi "asociali" non serve a gran ché: alla
fine si ha la necessità di far dialogare processi (non necessariamente
concomitanti o in esecuzione concorrente fra di loro) attraverso lo scambio
di dati.
Basandoci su queste affermazioni che, benché alquanto imprecise e
superficiali, sono universalmente accettate, quel che ne viene fuori è che
la più rudimentale forma quanto diffusa di IPC (che letteralmente significa
"comunicazione fra processi") è il file: questa forma di IPC, definibile con
un termine moderno e alla moda "off-line", permette lo scambio di
informazioni fra processi, eliminando il problema del "mondo chiuso" che il
modello di computazione basato sul multitasking introduce e fornendo altre
semplificazioni e vantaggi che per semplicità lasciamo alla letteratura
(vedi Stevens et al.)
Da questo discorso si evince che le pipe (ovviamente....) sono una forma di
IPC: rudimentale, non c'è dubbio, ma una forma di IPC perché consentono
l'interscambio di informazioni fra processi. Discorso analogo si può fare
per le socket: non ci sono più i pid (e qual è il problema?), ma degli
identificaitvi numerici chiamate porte, ma sono sempre forme di IPC. Se
vogliamo usare un linguaggio "pomposo", possiamo dire che le socket sono la
più avanzata forma di IPC per fare comunicazione tra processi a meno della
località di esecuzione.
Le forme di IPC più avanzate, e che per comodità potremmo definire
"propriamente dette", possono essere suddivise in due grandi categorie:
quelle basate sullo scambio di messaggi e quelle basate sulla memoria
condivisa. Negli anni si sono creati due blocchi contrapposti di
sviluppatori che hanno sostenuto una delle due forme di IPC, adducendo
motivi più o meno convincenti sulla validità delle stesse: c'è ne sono
alcuni oggettivi (che possono essere reperiti nelle normali guide sull'IPC)
e altri soggettivi, che comprendono anche l'approccio "estetico", se così si
può dire. Inoltre non bisogna mai dimenticare, che le soluzioni tecnologiche
non si scelgono in base alle "mode" o ai gusti estetici, ma bensì dopo un
attenta analisi dei requisiti di sistema e delle funzionalità del progetto
che si sta realizzando.
Per quanto riguarda la presunta "inefficienza" (che non è ben chiaro se si
riferisce a questioni di "inefficienza estetica" o che) di alcune forme di
IPC tra cui la memoria condivisa (storicamente ritenuta proprio la più
efficiente di tutte), francamente non ne vedo il riscontro.
Piuttosto è il caso di spendere qualche parola sulla questione dell'
"orrore" delle API e (presumo) delle funzionalità offerte dalle classiche
forme di IPC fornite da UNIX e derivati. L'obiettivo delle API UNIX e POSIX
sull'IPC è sempre stato quello di forinire l'approccio e le funzionalità di
base per fare IPC, senza fronzoli e quant'altro, e limitandosi ad un set di
API che, oggettivamente spartano, dia al programmatore la possibilità di
fare IPC.
Il problema di fondo è che nessuno mette in disucussione che le API IPC
danno molto poco al programmatare (che deve svolgere un lavoro più o meno
complesso per gestirle al meglio), ma non bisogna mai dimenticare che tutta
la teoria sul parallelismo e la gestione della concorrenza ci dice che ogni
qualvolta vogliamo "potenziare" i sistemi di gestione dell'IPC (in
particolar modo la memoria condivisa) aggiungendo nuove funzionalità che
permettono di sfruttare al meglio la forma di IPC anche da un punto di vista
della programmazione in sé, si complica inevitabilmente tutta la parte di
gestione perché i problemi da affrontare non sono pochi e spesso
irrisolvibili, tranne se applicati a contesti particolari.
L'approccio dell'IPC alla UNIX (così come tutta la filosofia di UNIX - per
cui rimando la lettura al libro "Practical UNIX development") è sempre stato
quello di fare le cose con "semplicità", demandando a terzi e a librerie il
compito di complicare (e rendere più "potenti") le cose.
Infine, reference counting et altro non ha nulla a che vedere con IPC: sono
artifici introdotti per la gestione concorrente delle risorse.
Saluti
--
Don't you know why your Python application has crashed?
Take a look to 
http://www.pycrash.org
My Home Page 
http://cnoviello.altervista.org
Sei un programmatore Python? E allora leggi PyJournal.it (
www.pyj.it
)

  Restando su livelli "scolastici",[...]
Tutto bello meno il quoting :(
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

> Nè nessuno implementa POSIX IPC, 
FUD.
Luca
-- 
Home: 
http://kronoz.cjb.net
K.R.O.N.O.S
Kinetic Replicant Optimized for Nocturnal Observation and Sabotage

 Luca


  >>>>> e nessuno le usa perchè sono degli orrori inefficienti
vero, infatti ad esempio...
# ipcs 
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x0052e2c1 0          postgres  600        10436608   1                       
0x00000000 32769      root      777        49152      1                       
0x00000000 65538      root      777        16384      1                       
0x00000000 131075     piccia    600        393216     2          dest         
0x00000000 163844     piccia    600        393216     2          dest         
0x00000000 196613     piccia    600        393216     2          dest         
0x00000000 229382     piccia    600        393216     2          dest         
0x00000000 262151     piccia    600        393216     2          dest         
0x00000000 294920     piccia    600        393216     2          dest         
0x00000000 327689     piccia    600        393216     2          dest         
0x00000000 360458     piccia    600        393216     2          dest         
0x00000000 393227     piccia    600        393216     2          dest         
0x00000000 425996     piccia    600        393216     2          dest         
0x00000000 458765     piccia    600        393216     2          dest         
------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x0052e2c1 0          postgres  600        17        
0x0052e2c2 32769      postgres  600        17        
0x0052e2c3 65538      postgres  600        17        
0x0052e2c4 98307      postgres  600        17        
0x0052e2c5 131076     postgres  600        17        
0x0052e2c6 163845     postgres  600        17        
0x0052e2c7 196614     postgres  600        17        
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
gli shared memory in questione sono usati da postgres, X, gnome-session,
gnome-terminal, metacity, gnome-panel, nautilus, mixer_applet2, wnck-applet.
I semafori sono di postgresql.
-- 
addio, e grazie per tutto il pesce