Named pipes bufferizam dados em HD ou RAM??

Ola pessoal,

Alguem sabe se named pipes (mknod(2)) bufferizam as informacoes entre o processo A (write()) para o processo B (read()) em disco ou em RAM??

O arquivo-pipe eh criado em disco (para q 'qualquer' processo possa fazer open()). MAS, reparei q o tamanho do arquivo nao muda, eh sempre 0 (mesmo com dados 'armazenados').

Preciso trocar dados da maneira mais rapida possivel entre 2 processos (sem nenhum parentesco: fork(), exec(), etc).

Shared memo. seria outra saida, mas complicaria em 10 a implementacao e, deve ser muito mais lerdas do q named pipes SE essas forem em RAM (IMHO).

(sockets nem pensar :) )

Valeu! Brigado!

-------------------------------------
a2gs
C/C++ POSIX code 4 Sex, Money & Fun!! Eh claro!

sem parentesco??? threads num resolve teu problema?

shared memory e semaphores e interessante para voce acessar uma regiao em comum de memoria que voce queira... mas como fosse disse complicaria um pouco o codigo.

jah que voce nao tem como fazer childs voce vai ter que usar essa saida de shared memory ou entao como fez diz ae usando named pipes, eu nunca trabalhei com nenhum dos dois, afinal eu nao sou programador, mas eu desconfio que ambos sao trabalhados na memoria RAM.

Duvido muito que seja em disco, acho que voce vai ter que ler o man pages ou uma documentacao mais detalhada para tirar a duvida de fato, mas o meu piteco vai para RAM :)

Também acredito q seja seja processado em ram.
O kernel do linux tem como caracteristica escrever em ultimo caso na partição de disco, primeiro ele vai utilizar /dev/ram depois a swap e por ultimo o disco para evitar fragmentação. ele guarda em arquivo de paginação em memória, isso desde o 0.6.* .
Talvez vc tenha q utilizar semaforos mesmo... que são uma boa pratica
ou os ja citados named pipes.

Abraços.

humm... certo.

eh, na verdade verdadeira eu nao falei, mas a comunicacao seria entre threads: o processo A ira criar (por exemplo) 5 threads e o processo B, 5 threads (por isso q nao eh uma boa usar sockets). Eles devem se comunicar numa relacao de 1 pra 1.
(Se eu fosse usar apenas 2 ou 3 pipes, poderia remanejar STDIN_FILENO/STDOUT_FILENO/STDERR_FILENO via um processo X, que carregaria A e B, +/- (mais pra menos) como o qMail... mas, no way)

Estava vendo o fonte do mknod(), passei pela sys_mknod(), vfs_mknod() e dai em diante nao consegui mais acompanhar (meu kong-fu precisa melhora muuuuito ainda :) (fs/namei.c))

Procurei na inet, achei 1001 textos explicando como usar mknod(), mas nenhum explicando a sua implementacao. Precisava de alguma literatura como 'Linux Kernel Internal' ou algo assim... e nao tenho.
Tentei intepretar o man da forma mais detalhada possivel, mas ele nao da nenhuma pista de como o write()/read() funcionam sobre pipes. Apenas diz sobre a criacao do arquivo-pipe em disco e do acesso ao pipe via credenciais (como qualquer arquivo, mas ate ai, eh coisa do open(), nao tanto do write()/read()).

Bem... farei assim, a primeira versao usarei named pipes pra nao ficar complicando muito (melhor do q threads acessando shared memo) e entregar o projeto mais rapido possivel. Depois, com mais tempo, implemento uma versao com shared memo. Faco um benchmark das 2 versoes e descrevo o resultado aqui pra futuras pesquisas/curiosidades ;)

(Li por cima algo sobre 'Handle Passing' no livro UNP1 do Richard Stevens (esse eh "O Cara" :) ): a ideia eh passar descriptors entre processos (como se fossem simples dados)! Mas terei q ver melhor... parece q pra essa ideia terei tambem q ter o tal processo X)

Valeu galera!! Brigado mesmo! Qualquer ideia eh bem vinda, e o q eu conseguir fazer/descobrir, descrevo aqui.

-------------------------------------
a2gs
C/C++ POSIX code 4 Sex, Money & Fun!! Eh claro!

É cara vc pode encontrar bastante documentação no kernel.org
ou na linux.org.

Eu nunca precisei chegar em tão baixo nivel pra trabalhando em um
sistema, mesmo os complexos, mas tudo q sei sobre o modelo de
processamento do kernel eu aprendi la. o man é fraquinho quando
se trata de devel.

Depois posta a implementação pra gente dar um bizu.
Abraços.

Tudo certo ai hez4el?!?

Do www.linux.org fui pra tldp.org, e achei um texto MUITO BOM:
http://tldp.org/LDP/tlk/tlk-toc.html
Item IPC Mechanisms, topico 5.2: Pipes.

Named pipes chegam a usar a VFS (virtual fs, Item 9, topico 9.2 do mesmo link), ao contrario de pipes simples (pipe(2): para processos com parentesco e q nao possuem nenhuma relacao do fs (isto eh, inodes)).

Ainda nao li direito, mas o VFS faz cache em memoria RAM de uma forma MUITO MUITO eficiente (tentando aliviar ao maximo trabalho de dispositivos (HDs, flash cards, opticos, e todos os outros meios de armazenamento fisicos 'montaveis' no linux), conforme vc tinha dito anteriormente: primeiro em RAM e por ultimo em swap/disco).
Como eu vou ter um processo B em BLOCK no read() esperando dados no pipe pelo produtor (processo A) antes mesmo do proprio (produtor) fazer write(), eh bem capaz q nao haja tempo de fazer cache em disco!! hehehehehe Estou especulando ao maximo... mas espero q esteja certo.

Bem... ainda estou especificando tecnicamente o programa (fazendo uma especie de 'diagrama de fluxos' o mais tecnico possivel (proximo ao codigo fonte) para ajudar o babaca, filho duma rapariga do programador (eu! hehehe)) pra depois comecar a escrever o codigo, mas assim que tiver algumas linhas de codigo funcionais eu posto aqui sim.

ps: nao eh atoa q esbarrei com a funcao vfs_mknod()!! VFS! :)

Valeu cara!