Newsgroup: it.comp.os.linux.development
Titolo: system()

Normalmente la system aspetta che venga eseguito tutto il comando al suo
interno prima di terminare. 
Se ho un comando di durata abbastanza lunga se al comando metto & per
farlo andare in background la system ritorna prima e il programma va
avanti lo stesso?
-- 
Non c'č piů forza nella normalitŕ, c'č solo monotonia.

avanti lo stesso?
Perche` invece di chiederlo qui non ci provi?
Comunque ti conviene usare fork ed exec.
-- 
ciao, | * The Internet is full. Go away.  -- Joel Furr *
Marco | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 avanti lo stesso?
A non fai prima a provare?  :)
In ogni caso è una soluzione fortemente dipendente dalla schell che usi
e, quindi, poco portabile.
Usa fork() e exec().
Ciao,
Fabio Alemagna

 interno prima di terminare. 
 
Potresti usare (v)fork() + exec().
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

8-o
-- 
Non c'è più forza nella normalità, c'è solo monotonia.

 del processo, ma solo una soluzione per non dover passare per i thread
No, non ti copia un bel nulla, linux usa il demand paging quindi non ha
da copiare nulla (copia solo le pagini se ci scrivessi sopra, ma siccome
fai un exec non lo fai), deve solo generare le entries nella process
table (cosa che deve fare comunque); vfork e' assolutamente deprecata
(non ha nessun senso in linux) e anche i thread non servono in termini
di prestazioni (sono equivalenti ai processi, solo condividono lo spazio
indirizzi delle variabili). 
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

 del processo, ma solo una soluzione per non dover passare per i thread
non copia nessun processo.
Ciao,
Fabio Alemagna

 del processo, ma solo una soluzione per non dover passare per i thread
$ man vfork


 (non ha nessun senso in linux) 
[root@fokhouse /root]# man vfork | col -b | grep -A4 \\w\ clone
       vfork() is a special case of clone(2).  It is used to cre
       ate new processes without copying the page tables  of  the
       parent process.  It may be useful in performance sensitive
       applications where a child  will  be  created  which  then
       immediately issues an execve().
[root@fokhouse /root]#


Comunque ti conviene usare fork ed exec.
non e' meglio vfork?
ciao

 codice non portabile. E' anche una questione di eleganza...
è un programma che va messo su un CD live con linux e basta. So anch'io
che la soluzione fa cagare, ma ho poco tempo. Comunque forse ho risolto.
Ciao


non e' meglio vfork?
No. Non usare *mai* vfork se non si sa il perche`.


Perche' ?
Perche` non su tutti gli OS ha la stessa semantica di fork e si rischia
di farsi male. Le prestazioni sono praticamente identiche.


No. Non usare *mai* vfork se non si sa il perche`.
beh evidentemente se l'ho citata avro' avuto un motivo... dato che
comunque la prima cosa che dovr' fare nel nuovo processo sara' una
exec, mi pare inutile ereditare le risorse del padre...
come mai NON bisogna utilizzarla?
ciao

 [root@fokhouse /root]#
Se leggi cosa c'e' scritto poco sotto troverai:
BUGS
       It is rather unfortunate that Linux revived  this  spectre
       from  the past.  The BSD manpage states: "This system call
       will be eliminated when proper system  sharing  mechanisms
       are  implemented.  Users  should  not depend on the memory
       sharing semantics of vfork as it will, in  that  case,  be
       made synonymous to fork."
conviene completare la lettura della man page per vedere che la
differenza di performance e' insignificante, contro una lunga serie di
problemi. 


serve ed e' deprecata.
a quanto ne sapevo la vfork era un alias fino a linux 2.0, poi nel 2.2
e' diventata una funzione effettiva, usata poi nelle librerie dei
thread... o mi sto sbagliando clamorosamente?
ciao

 kernel/vfork.html | grep -1 win
   A good amount of effort was directed at making COW better in [2]UVM,
   but an address space-sharing vfork() still turns out to be a win. It
   shaves several seconds off a build of libc on a 200MHz PPro.
[root@fokhouse /root]#
Ti faccio anche notare che, mentre nei kernel 2.0.x vfork() era un alias
per la fork(), nel 2.2 è stata reintrodotta una 'vera' vfork().


thread... o mi sto sbagliando clamorosamente?
Non ha nulla a che fare con il threading.


[root@fokhouse /root]# lynx -dump 
http://www.netbsd.org/Documentation/\
Un pedante potrebbe fare notare che linux non e` netbsd e quindi non e`
particolarmente rilevante affermare che con il secondo vfork e`
marginalmente utile.


 
Credo tu ti stia confondendo con clone(2).
Max

Credo tu ti stia confondendo con clone(2).
thread a parte, mi sbaglio anche sul fatto che in linux 2.0 NON c'era
la vfork mentre in 2.2 si?
cmq ho capito tutto ora, grazie.
ciao

 marginalmente utile.
E poi si chiederebbe: "Però se fosse così inutile e foriera di problemi, 
perché mai la avrebbero reintrodotta anche nel primo ?".


 la vfork mentre in 2.2 si?
No. Hai ragione, c'è scritto nella man page, c'è scritto pure in un
mio post nello stesso thread.


 [root@fokhouse /root]#
Ma quello si riferisce a netbsd, che ha una implementazione differente
(a quel po' che ho sentito dire).
Non capisco cosa c'entri linux, e non mi risulta che con linux ci siano
tutte queste differenze. E i motivi per cui e' deprecata stan scritti
sulla man page, credo sia stata implementata in quel modo per motivi di
compatibilita', ma mi ricordo una discussione riportata su
kernel-traffic a proposito della man page e sul fatto che l'autore ci
voleva andare giu' molto piu' duro sul fatto di usarla (volava del
brain-damaged implementation).


 brain-damaged implementation).
Un'altra cosa che in effetti si nota dalla man page è che l'autore
non è molto ...convinto. ;)
Comunque grazie del suggerimento, andrò a scavare da quelle parti.
