Re: [Linuxcall] Qual a melhor forma ???

[C. <al...@br...>]

Marcelo Beckmann wrote:
> 
> -------------[ explicação/resumo sobre execve() ]------------------
> #include <unistd.h>
> 
> int execve(const char *filename, const char *argv[], const char
> *envp[]);
> 
> Essa função recebe três argumentos:
> [*] O nome de arquivo do programa executável binário ou do script do
> interpretador;
> [*] O array argv[] a ser passado para o programa;
> [*] O array envp[] de variáveis de ambiente a exportar;
> 
> ------------------------[ /execve() ]------------------------------
> 
> manja a declaração completa de main?

manjo...

> int main(int argc, char **argv)

> A grande vantagem de execve() em relação ao system() é que o programa
> chamador (o processo pai) não fica preso, possibilitando um controle
> melhor das coisas....

Hum.... isso é interessante. Foi justamente isso que eu ressaltei no
primeiro mail: se naum fosse assim tão necessário executar códigos após
a chamada ao pppd, a função bem que poderia ser a system()... mas andei
lendo as páginas de manual das exec** e elas são mais powered... :P

> //  > Hum....  pano pra manga ai....    Depois do pppd a gente nao vai
> //  > executar mais nada nao?  E os scripts pré e pós discagem?
> //
> //  O script pós discagem é fácil, o pppd retorna se conseguiu conectar...
> //  aí a aplicação-mãe roda o processo...
> 
> Andre, um detalhe ai....
> 
> O pppd só retorna quando a conexão terminar.
> 
> Se o processo pai usar system(), todo o processo pai ficara preso até
> que o pppd retorne...

Opa. Vc está equivocado meu caro amigo :P

Quando executamos o fork() e criamos o processo-filho, a aplicação-mãe
continua rodando... independente se o processo filho está "travado" ou
não com a função system().

> Ou seja: não será possivel clicar num botão de "desligar" no
> processo/programa pai, por exemplo, por que o pai estará com o
> processamento preso durante esse tempo - para liberá-lo, o pppd
> precisa morrer....

Será possível sim! :P

A qualquer momento que se queira, é possível encerrar o
processo-filho... leia mais adiante... :-)))

> //  > Não é por nada não, mas pra gente que já trabalhou com os
> forks e //  > afins usar system() me parece meio paia ai ó....
> //
> //  System() naum é paia naum! :-P
> //
> //  É uma mão na roda quando precisamos executar comandos de shell a partir
> //  de um programa C... :P
> 
> Tudo depende da abordagem, da situação:
> * processo filho é "pequeno" ou "grande";
> * a execução do processo filho é rápida ou demorada;
> * o processo pai deverá operar em modo BLOCKING ou NOM BLOCKING;
> * facilidade de implementação de uma forma ou outra;

Hum... isso é vero. Acabei constatando esse detalhe ao ler com mais
atenção as man pages dos exec**...

Nesse caso, em específico, pouco importa o que o processo-filho irá
fazer... naum, eu naum estou ficando maluco. :P

O processo filho roda INDEPENDENTE do processo-pai. O processo pai pode
até ser encerrado, que o filho continua... sem problemas...

> //  Minha ideía, caros coders, é que o processo-filho (onde vai
> estar a //  chamada ao pppd) tenha o mínimo de código... Só mesmo
> executa o pppd e //  comunica com o processo-pai via IPC... mais nada.
> 
> Via system() creio que não será possivel usar IPC (pelo menos para
> semaforos, shared memory, e possivelmente pipes). Por que?
> Por que com system, o processo pai fica preso (modo BLOCKING), e se
> ele está preso, ele não executa nada, portanto, não poderá acessar um
> semaforo ou uma shm _enquanto_ o processo filho estiver rodando.

Isso é que é o chato da estória toda... a tal da Intercomunicação entre
os processos... vulgo IPC :)

Lembra que a gente tava pensando em fazer que nem o "concorrente" (kppp)
???

Eles usam sockets... :)

Aí eu fui pesquisar mais sobre isso. Sintam só coders:

-------------------------->8=====================[corta]

DESCRIPTION
       Socket creates an endpoint for communication and returns a
descriptor.

       The domain parameter specifies a communication domain; this
selects the protocol family which will be used for communication.  These
families are defined in <sys/socket.h>.  The currently understood
formats include:

       PF_UNIX, PF_LOCAL
		UNIX protocols for local communication

------------------------->8======================[corta]

Maneiro, né ? -->  UNIX protocols for local communication

IPC via sockets...

Pesquisando mais um pouquinho... vejam só:

------------------------->8=======================[corta]

SOCKETPAIR(2)       Linux Programmer's Manual       SOCKETPAIR(2)

NAME
       socketpair - create a pair of connected sockets

SYNOPSIS
       #include <sys/types.h>
       #include <sys/socket.h>

       int socketpair(int d, int type, int protocol, int sv[2]);

DESCRIPTION
       The  call  creates  an  unnamed pair of connected sockets in the
specified domain d, of the specified type, and using the optionally
specified protocol.  The descriptors used in referencing the new sockets
are returned in sv[0] and sv[1].  The two sockets are indistinguishable.

------------------------>8=======================[corta]

Pelo pouco que eu pude entender nessa olhadela que eu dei, o conceito de
sockets para o IPC é extremamente semelhante ao de pipes...

Mas naum akeles pipes com popen e tal... são akeles mais "baixo-nível"
com pipe(fd); etc...

Tem-se uma canal de escrita fd[0] e um canal de leitura fd[1]... 

Só que nos sockets dá prá retirar mais informações do processo... acho
que é isso...

Ô Amauri, vc que é fera nesse negócio de sockets... dá uma luz prá gente
aki... :PPP

> //  Acho que assim fica melhor... dá prá controlar beleza...
> 
> Pense bem sobre o system(), dependendo da abordagem ele não será
> adequado para os propósitos que temos em mente...

Eu já estou descartando o system() devido àquele lance do IPC... 

> E o que temos em mente???
> 
> Dominar o mundo, claro!!!
> Não precisa ser amanhã...
> Pode ser na semana que vem....
> 
> hawhuiahawhuiahawhuiahawhuiahawhuiahawhuiahawhuiahawhuiahawhuia
> 
> (esse negócio de irc vicia....  :)

UAUhAUhAueuhAUhAUhuhAUhAeA 

vicia mesmo... :)

> //  E lembrem-se: Os dois processos rodam COMPLETAMENTE em separado... dá
> //  prá fazer praticamente QUALQUER coisa... :P
> 
> Mas isso não acontece com system(), por que enquanto o processo FILHO
> está RODANDO o processo PAI está PARADO (preso, bloqueado).

NAO! De uma vez por todas: Processo pai roda independente de
processo-filho e vice-versa...

Se um morrer, o outro continua sem problemas...

> Uma outra coisa, que eu estou desconfiando que é possível, é que
> seria possivel o pai ter um controle do processo fiho (matá-lo com
> kill), o que seria interessante pra implementar um botao de
> "cancelar" para o usuario poder interromper o pppd e abortar a
> conexao.
> Quanto a esse detalhe, ainda preciso confirmar se isso é mesmo
> possivel, ai quando eu souber eu passo pra voces a informação mais
> precisa...

Bom, naum precisa pesquisar mais. Eis a resposta... :P

	kill(pid_processo_filho, SIGTERM);

E se tiver teimando em naum obedecer a gente pode apelar...

	kill(pid_processo_teimoso, SIGKILL); :PPP

> //  Bom, é isso aí... aguardo comentários,
> 
> Beleza, os meus estão ai.

Os meus tb... mais algum comentador por aí ? :)))

> Lembra os fontes do livro blablabla 24 horas que eu te passei?

Lembro sim...

vou até comprar esse blablabla em 24 horas... parece ser bem legal... o
Volkerding é co-autor... deve ser fodão mermo... :-)

> Então, da uma olhada nos do capitulo 18 (arquivos 18LST**.c), tem
> vários exemplos lá. Mais de noite, no irc, a gente tb pode ver mais
> sobre isso.

Legal... vou ver sim...

> Ah, e como é que você tá ai mano? Melhorou da febre e coisa e tal?
> Tomara que voce melhore o quanto antes, não vejo a hora de te ver no
> gaz de novo.

Até hoje (quarta) pela manhã eu ainda tava meio baqueado... mas melhorei
já e tou voltando ao velho gaz... hehehe

> Hurrruuuu! Abração ai tb.

Huuurruuuuuu......... é isso manow... vamos nessa!

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ Linux User: # 178853	Machine: # 79923      ]
[ Linux Heavy User - Powered by Slackware 7.1 ]
[ http://www.geocities.com/andre_casteliano/  ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
[        LinuxCall - The Linux Dialer         ]
[      http://linuxcall.sourceforge.net       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+