[Cascavel-pm] como garantir file lock para outros programas?

Alceu R. de Freitas Jr. glasswalk3r em yahoo.com.br
Quinta Janeiro 26 05:33:15 PST 2006


Oi Breno,

--- "Breno G. de Oliveira" <breno em clavis.com.br>
escreveu:

> eu também procuro a algum tempo uma boa maneira de
> implementar file
> locking com Perl. Respondendo a sua pergunta sobre
> ter "alguma
> segurança" com programas feitos em outras
> linguagens, vale lembrar que o
> locking é voluntário, ou seja, se o outro programa
> não implementar
> locking ele vai conseguir escrever no arquivo numa
> boa (como vc mesmo
> lembrou).

Seus testes com C e pesquisa sobre os detalhes de
implementação ajudaram a esclarecer melhor o problema
e estabelecer alguns limites. Obrigado! :-)

> Também duvido que o samba não implemente locking,
> mas pra garantir
> testei seu programa contra esse codigo em C que fiz
> implementando
> locking via fcntl():

Eu tentei ler os fontes do Samba mas isso me causou
dores de cabeça horríveis... rs
Simplesmente pesquisar nos arquivos .C e .H por flock,
lockf e fcntl não trouxe resultados também. Como eu
tentei a lista do Samba e não obtive respostas sobre o
assunto (eles estavam preocupados demais com o
lançamento do Samba 4) eu não consegui descobrir isso.
Mas como você explicou mais abaixo, não acho que faça
muita diferença.

> Infelizmente, como pôde ser constatado, testar
> locking de programas que
> não os seus é inviável (senão impossível) sem que
> saibamos exatamente
> qual o tipo de locking empregado (como foi o seu
> caso no samba), ou sem
> um sistema operacional que faça locking mandatório
> (nesse caso, qualquer
> locking bloquearia chamadas de sistema para escrita
> - e isso não costuma
> dar muito certo).

Até aonde minhas pesquisas me levaram, sistemas UNIX
não implementam file locking mandatório. Sistemas como
MS Windows usando FAT32 e NTFS já fariam isso (eu
acho). Mas locking mandatório causa seus próprios
problemas.

> Uma solução seria usar o flock() e o fcntl() logo
> depois no mesmo
> arquivo, mas isso gera deadlock em sistemas com
> flock emulado ou que
> usem a mesma syscall para ambas as funções. Para
> contornar esse
> problema, se déssemos o flock() mas o fcntl()
> bloqueasse, pediríamos o
> PID do processo "dono" do lock e, caso seja o
> próprio programa, esse
> poderia continuar normalmente.

Eu cheguei a conclusão de que é mais simplesmente usar
os próprios programas do sistema que você quer
compatilhar o(s) arquivo(s) ou então usar suas
bibliotecas.

No caso do Samba, me pareceu MUITO mais razoável
utilizar suas bibliotecas de DCE/RPC e fazer as
chamadas necessárias para que o próprio Samba fizesse
o serviço. Fiz uns testes usando Active Perl e o
módulo Win32::NetAdmin e funcionou perfeitamente. 

O problema que é o Windows já vem com essas biblioteca
disponibilizadas e o Win32::NetAdmin fornece a cola
necessária. Para ter algo parecido no Linux, eu teria
que utilizar C (libmrpc.h do Samba), XS e Perl. Mexer
C já seria uma boa dor de cabeça, aprender XS então,
nem se fala.

Passeando pelo perlmonks.org eu descobri que o
Chromatic está desenvolvendo um módulo para fazer algo
parecido com o que existe hoje para o módulo Win32API
aqui: http://use.perl.org/~chromatic/journal/20481. Eu
ainda não testei, mas basicamente permitiria usar
bibliotecas em C/C++ sem ter que usar XS (mas com
perda óbvia de performance).

> Infelizmente não pude continuar esse teste pois não
> me entendi com a
> sintaxe da função fcntl() no Perl...

Até aonde eu entendi, fcntl só fornece constantes
definidas na biblioteca C do SO que você está usando,
mais nada. O flock é que pode usá-la diretamente (se
flock e lockf estiverem ausentes).

Existem algums módulos no CPAN que implementam essas
funções diretamente usando C e XS. Seria possível usar
esses módulos com sucesso se você soubesse que esquema
o programa está usando.

[]'s



Alceu Rodrigues de Freitas Junior
--------------------------------------
glasswalk3r em yahoo.com.br
http://www.imortais.cjb.net
-----------------------------------------------------------------------
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1


	



	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 



Mais detalhes sobre a lista de discussão Cascavel-pm