[Tech] OT - Programmazione C

[Marco Ermini]

On Sun, 22 Feb 2004 20:19:12 +0100, Simone Piccardi
<piccardi@softwarelibero.org> wrote:

> On Sun, 2004-02-22 at 18:57, Marco Ermini wrote:
> > > > memoria liberata non viene ritornata al sistema operativo. Qualcuno
> > > > puòdare più informazioni? 
> > > No e` impossibile perche` i processi usano spazi degli indirizzi
> > > completamente indipendenti (per i thread il discorso e` ovviamente
> > > diverso, ma qui si parla di processi mi pare).
> > 
> > In Linux, thread e processi sono la stessa cosa (almeno fino a che non
> > prenderà piede la nuova glibc della RedHat compatibile POSIX).
> Beh, dipende parecchio da cosa intendi tu per la stessa cosa.

Guarda, non è cosa intendo io ma cosa sono in realtà... per quello che
ho potuto vedere io (suscettibilissimo di errare, per carità) Linux è
un'implementazione di Unix molto "particolare" che ha poco a che fare con
gli "Unix" intesi in senso stretto, è uno "Unix compatibile". Thread e
processi, storicamente, su Linux sono la stessa cosa, cioè sono trattati
allo stesso modo dal kernel (non so se adesso la cosa sta cambiando, ma mi
risulta che nel kernel 2.4 sia sempre così. Mi corregga chi ne sa di più).

Prova a fare un "ps -ex| grep httpd" su Solaris o su Linux (per httpd
intendo Apache) e su Linux (forse su Linux è ps aux) vedrai enne processi
(quanti sono i thread lanciati in fork da Apache), su Solaris ne vedrai
molti meno(tipo... uno solo, o due). Così in FreeBSD, Tru64, o in AIX - non
importa se è Unix SysV o BSD.


> Io una cosa (i thread, almeno quelli usati dai programmi attraverso la
> libreria pthread, la attuale) che necessita di un altro thread a parte
> per funzionare, che condivide lo stesso spazio di indirizzi invece di
> avercelo completamente separato, proprio la stessa cosa di un processo
> non la considero.

Però per Linux continuano ad essere praticamente la stessa cosa...


> E benche` nel 2.6 le differenze siano diminuite (dato che non c'e` piu`
> bisogno di un thread a parte per gestire i thread in stile POSIX) il
> fatto che in un caso lo spazio degli indirizzi sia condiviso e
> nell'altro no resta, ed e` la cosa che li rende completamente diversi ed
> il motivo per cui un processo non puo` allocare la memoria di un altro.

Ma in Linux, thread e processi continuano ad essere praticamente molto
simili. Te l'assicuro, questa è la mia esperienza, da esperto più di Unix
che di Linux in verità, ed avendo anni di sviluppo cross-platform nel mondo
Unix alle spalle, ed avendolo riportato (o avendoci provato) su Linux.

In pratica, Linux non fa una grande differenza tra "forkare" un thread o
lanciare un nuovo programma - non almeno quella che fa per esempio Tru64,
dove il tuning del meccanismo di fork prende quasi un quarto del manuale di
documentazione sullo sviluppo e sul tuning dell'OS, e dove è documentata
ampiamente la singola virgola che fa scatenare il meccanismo di
copy-on-write o meno (e pure *quale* dei meccanismi previsti).


> I process group non c'entrano nulla con l'allocazione della memoria.

Il sign. Richard Stevens, come gli autori di POSIX, non sarebbe d'accordo
con te (almeno Stevens non può più risponderci, comunque ;-)


> In
> genere servono alla shell per tenere insieme gli stessi processi
> lanciati su una linea di comando (quelli concatenati da una pipe, per
> intendersi) e potergli mandare dei segnali.

Simone ti consiglio, oltre al libro "Advanced Programming in the UNIX
Environment" di W. Richard Stevens - che però mi sa che conosci perché il
corso che tu "pubblicizzi" mi pare ne faccia incetta... - "Programming with
POSIX Threads" di David R. Butenhof e "POSIX.4: Programming for the Real
World" di Bill Gallmeister. Il sottoscritto purtroppo ha dovuto digerire
queste cose a lungo, pensa che quando Amazon è andata per la prima volta in
attivo, dopo 4 anni mi pare, volevano regalarmi delle azioni...


> Una trattazione si trova (ne
> riapprofitto per farmi pubblicita` e per evitare di riscrivere le stesse
> spiegazioni) su:
> http://www.lilik.it/~mirko/gapil/gapilse32.html#x357-20100010.1
[...]

Potevi fare pubblicità più fruttuosamente al libro di Stevens, però mi sa
che è un testo un po' vecchiotto e generico ;-)

Beh, almeno il tuo corso è in italiano...


> Non mi risulta affatto poi che Linux implementi poco di Posix.
[...]

Magari il cosa "risulta affatto" a te è più o meno utile o applicabile, a
seconda dei casi. Poi, ognuno ha avuto le sue esperienze, per carità.

Il fatto che il sign. Torvalds & C. non abbiano mai nemmeno posseduto le
specifiche, e che in realtà non gli freghi molto, non lo trovo comunque
irrilevante :-)

Divagando: si può discutere del fatto che la cosa sia più o meno importante
a livello di compatibilità... sono sicuro che il fatto che POSIX sia più o
meno implementato può anche avere poca importanza nel 95% delle
applicazioni, visto che i programmi girano comunque e l'hardware Intel costa
poco; la mia esperienza però è che mesi di ottimizzazione su Tru64 e AIX di
un programma C e C++ delicatissimo che forkava pesantemente si sono
dimostrati inutili su Linux 2.2 e 2.4, che faceva più o meno come gli pare,
facendo copy-on-write praticamente sempre, dove gli altri Unix invece
ottimizzavano.

Personalmente ritengo che l'implementazione di NPTL sia un grosso passo
avanti, e che se ci fosse stata prima, alcuni gasdotti oggi sarebbero
monitorati da Linux e non da AIX e Tru64. Peccato. Ma non mi dire che Linux
implementa POSIX quanto servirebbe a livello industriale, perché non è stato
così prima della RedHat 9. Almeno questa, ripeto, è la mia esperienza.

Poi possiamo fare i flame che ci pare, ma certe cose le si possono
raccontare giusto ai corsi del Flug... non venire a dire a me che a livello
industriale Linux più o meno ci ha tutto, e che "ti risulta che non gli
manchi molto di POSIX"... soprattutto a livello industriale, e soprattutto
quando devi monitorare un petroldotto che sta su una piattaforma al largo
dell'Angola e che è raggiungibile solo in elicottero, o quando il fatto che
il sistema swappi quando non dovrebbe rischiando di farti perdere dei dati
real-time che arrivano dai sistemi OPC e che si rischia che salti il
monitoraggio di migliaia di km di condutture in Messico... è importantissimo
avere dei kernel *stabili* (non con gli algoritmi che cambiano ogni due
giorni) e soprattutto *documentati* dove io sappia esattamente quanta
memoria verràusata quando succederanno certe cose.

</sfogo su Linux OFF>

Questo non vuol dire che Linux complessivamente non sia un ottimo OS... ma
che per certe applicazioni (il 5% dove Linux non entra) occorrono dei vendor
che garantiscano una stabilità ed una documentazione che nel mondo Linux
ancora è troppo scarsa.

E ci deve essere scritto nero su bianco che la creazione di un pthread
genera un copy-on-write solo quando si fanno certe cose, la cosa non cambi
se aggiorno dal kernel 2.4.18-1 al 2.4.19-2 o chissà in quali altri casi.

Per lo meno FreeBSD sai che funziona in quel modo là... il kernel viene
cambiato pochissimo (a livello soprattutto di scheduler) e la documentazione
è in pratica la sua storia.

Per cui, io non sono totalmente d'accordo con te. La mia esperienza è che la
programmazione POSIX su Linux è realmente molto limitata; penso che sia
troppo poco documentato, e che sia un sistema (kernel+glibc) ottimo in certi
ambiti ma ancora scarso in altri.

Poi ognuno riporta la sua esperienza, per carità.


> Quello meno implementato e` il 1003.1b per quanto riguarda i
> semafori e le code di messaggi (in stile Posix e non SysV).

Non faccio per dire, ma chissà di cosa stavamo parlando...


> Comunque direi di lasciar perdere, non ho voglia di rimettermi a fare un
> altro lungo flame, solo come tu stesso hai detto a qualcun'altro poco
> fa:
> 
> "Per favore se non si è sicuri di cosa si parla non "spariamole" a caso
> o per sentito dire."

Guarda Simone, io, almeno su queste cose, non parlo per sentito dire... e
se lo faccio, lo dico in anticipo... il flame puoi farlo se ti garba, si
vede che ti diverte, a me non è che mi freghi molto, se non per il fatto che
ti pregiudichi una occasione di confronto con chi ha esperienze discordanti
dalle tue, solo perché vuoi avere un atteggiamento presuntuoso.

Spero più che altro che Valerio non si sia spaventato...


ciao
-- 
Marco Ermini
http://macchi.markoer.org - ICQ 50825709 - GPG KEY 0x64ABF7C6 - L.U. #180221
Perche' perdere tempo ad imparare quando l'ignoranza e' istantanea? (Hobbes)
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        non disponibile
Tipo:        application/pgp-signature
Dimensione:  189 bytes
Descrizione: non disponibile
URL:         <http://lists.linux.it/pipermail/flug-tech/attachments/20040222/65abc15e/attachment.pgp>