Newsgroup: it.comp.os.dibattiti
Titolo: Tubi

http://www-106.ibm.com/developerworks/linux/library/l-rt4/?t=gr,p=Pipes
-- 
Lorenzo
(address rot13 encoded)

Praticamente tubi contro 'mbuti

Praticamente tubi contro 'mbuti
ROTFL!



facendo un test con blocchi un po' piu' grandi di 4096k (ma un po' piu' piccoli di 256M :-)) )
le cose sono meno catastrofiche ma non comunque dalla parte di Win2k, il fatto che xp faccia
schifo testimonia la grande 'experience' :-))
A parte tutto non credo che si possa valutare Win2k basandosi su quanto performa la pipe
(IPC pochissimo usato sulla piattaforma), in generale credo che le valutazioni sulle 'raw
performances' siano sempre delle idiozie.
Invece l'articolo e' interessante, in un marasma di cose inutili c'e' qualcuno che 'studia'
e 'prova' cosa che non fa mai male.
--
Antonio Baldassarra
anto...@seeweb.com

 
Dall'articolo:
------------------
Creating a Linux named pipe
int fd1[2];
if(pipe(fd1)) {
printf("pipe() FAILED: errno=%d
",errno);
return 1;
}
------------------
Non mi sarei mai aspettato di dover leggere una simile cavolata
da un "senior programmer" di IBM:(
man 2 pipe
man 3 mkfifo


wrote:

Un po' grezzo, ma corretto.
Meglio sarebbe stato:
int fd1[2];
if (pipe(fd1) < 0) {
	perror("pipe");
	exit(1);
}
Ma e' equivalente :)


 
Il problema e' un altro.
L'autore parla di named pipes, ma per crearle sotto Linux usa pipe(),
che puo' essere usata solo per le pipes classiche, quelle unnamed, non
utilizzabili all'esterno del processo che le ha create (o di un suo
parente o thread) perche' non virtualizzate tramite un oggetto del
filesystem, ma identificate dal solo file descriptor.
Per le named pipes bisogna usare o mknod(), o la piu' diretta mkfifo().
Inoltre, manca qualunque meccanismo di sincronizzazione per l'accesso ai
dati condivisi fra processo e threads, cosa che di solito rende
estremamente inaffidabili gli stessi dati.
Vabbe' che e' un benchmark, quindi ci si aspetta di tutto tranne la
correttezza dei risultati:), ma almeno dirlo nell'articolo avrebbe
giovato.
IMO, e' un esempio di cattiva programmazione che IBM farebbe bene a
togliere di mezzo, prima che qualcuno lo usi come spunto per del codice
da usare in progetti mission critical e ammazzi delle persone.

da usare in progetti mission critical e ammazzi delle persone.
Se chiami questo cattiva programmazione allora forse non hai mai visto
un esempio di vera cattiva programmazione :)


 un esempio di vera cattiva programmazione :)
Sigh, purtroppo li ho visti eccome...:(

Sono implementate con un filesystem virtuale, pipefs.
So che non c'entra nè significa niente, ma anche in Windows sono un file 
system:
ALDEBARAN\Administrator [d:\home\hyperion]
::objdir \DosDevices|grep PIPE
PIPE                             SymbolicLink - \Device\NamedPipe
ALDEBARAN\Administrator [d:\home\hyperion]
::dir \\.\PIPE\*
 Directory of  \\.\PIPE\*
                              2  epmapper
                              3  lsass
                              1  net\NtControlPipe0
                              1  net\NtControlPipe1
                              1  net\NtControlPipe2
                              1  net\NtControlPipe3
                              1  net\NtControlPipe4
                              1  net\NtControlPipe5
                              1  net\NtControlPipe6
                              1  net\NtControlPipe7
                              1  net\NtControlPipe8
                              1  net\NtControlPipe9
                             25  ntsvcs
                              2  ProfMapApi
                              6  ROUTER
                              2  scerpc
                              1  SecondaryLogon
                              2  SfcApi
                             10  Spooler\LPT1
                              2  spoolss
                              2  tapsrv
                              1  Win32Pipes.000001f0.00000001
                              2  winlogonrpc
                              1  Winsock2\CatalogChangeListener-190-0
                              1  Winsock2\CatalogChangeListener-f0-0
                              2  WMIEP_208
                              2  WMIEP_414
                              2  WMIEP_fc
             78 bytes in 28 files and 0 dirs
              0 bytes free
La differenza è nella semantica, le pipe si usano come se fossero delle 
socket (perchè tra l'altro funzionano anche su NetBIOS), con tanto di 
listen, accept, connect, eccetera, sono perfettamente equivalenti alle 
socket connection-oriented, con in più un meccanismo di autenticazione-
impersonazione integrato (difatti come vedi vengono usate principalmente 
dai servizi)


Allora sospetto che le "\Device\NamedPipe" che hai riportato siano in
realta' l'equivalente delle AF_UNIX che si creano con socketpair(2).
Non sono propriamente delle named pipe, perche' hanno qualcosa di piu'
delle named pipe ma non dovrebbero averlo dal momento che questo
qualcosa in piu' lo offrono gia' le socket di per se'.
Inoltre, le vere named pipe sembrano in realta' non esistere.
Piuttosto strano..
Portando la semantica delle socket sulle named pipe appesantite
inutilmente un meccanismo (le pipe) la cui semplicita' di utilizzo ed
implementazione e' la sua virtu' principale. Non sei d'accordo?


ed implementazione e' la sua virtu' principale. Non sei d'accordo?
Come t'ho già detto, le cose si fanno semplicemente in un modo diverso. 
In Windows c'è quella mano santa chiamata COM, a cui affidare scelte 
noiose come il meccanismo IPC più adatto al caso particolare. Sì, la 
pipe è semplice, è veloce, ma è ancora più semplice chiamare 
direttamente una funzione. Nel peggiore dei casi, se entrambi i processi 
sono sulla stessa macchina, si tratterà di una LPC, meccanismo 
velocissimo (si tratta praticamente di due context switch e poco altro, 
come buffer si usa una sezione di memoria condivisa tra il processo 
client e il server, quindi non è necessaria alcuna operazione di copia), 
e soprattutto libero dall'infernale struttura stratificata dei driver di 
periferica (è implementato direttamente nel kernel)