Newsgroup: it.comp.programmare.win32
Titolo: processi in C

Qualcuno mi sa indicare quale libreria e quali funziona si utilizza per
avviare piu processi su C in ambiente windows???

 avviare piu processi su C in ambiente windows???
La domanda è chiaramente malposta... Windows ha più processi in esecuzione
contemporaneamente punto. (se tu lanci il Word e l'Excel in contemporanea
hai due processi senza scrivere una riga di C)
Comunque leggiti: CreateProcess, CreateThread e ShellExecute sull'msdn.
(
msdn.microsoft.com
)
--- bye

 La domanda č chiaramente malposta... Windows ha piů processi in esecuzione


 > (
msdn.microsoft.com
)
Ti ho già dato la risposta :-)
Lo sapevo di cosa parlavi :-) Ma lo stesso devi cercare di essere più
specifico. Inoltre non hai specificato a cosa ti serve... Devi lanciare un
vero e proprio programma "figlio" diverso, o devi creare un altro thread?
(Per creare processi veri e propri guarda la prima e la terza, per i thread
la seconda)
--- bye

 ha scritto nel messaggio
news:TZV4c.43035$z23.1...@news3.tin.it...


 ma io uso c della borland le msdn nn so a cosa possano servirmi!
Allora a te le informazioni piace darle a pezzi, eh?
Dunque, per un server su un sistema operativo moderno NON usi il fork! A
scelta usi i threads, usi le fibers o usi l'asynchronous IO (di solito si
usano un paio del primo e molto molto del terzo... Qualcosa del tipo un paio
di threads per ogni processore e tutto il resto con l'Async IO)
Eppoi... Adesso salta fuori il fatto che usi il Borland... Dirlo prima no,
eh? Comunque l'MSDN contiene tutte le API di Windows. Quindi centra
sempre... Forse la Borland include il manuale del Platform SDK... Va bene
anche quello. Per finire, visto che usi il Borland, cerca nel suo manuale
BeginThread mi sembra... Devi usare la sua funzione per iniziare il thread
in maniera che possa allocare certe cose per se stesso.
--- bye


Scusa se mi intrometto: Io avevo sempre considerato i thread come la 
soluzione ad hoc per gestire richieste dei server. Nel senso, piazzavo 
un thread in attesa di connessioni sulle porte, poi creavo un thread per 
ogni client che dovevo gestire. Da quel che leggo, stai proponendo una 
soluzione più leggera (anche se forse più complessa dal punto di vista 
realizzativo). Dove potrei trovare maggiori informazioni in proposito?

 realizzativo). Dove potrei trovare maggiori informazioni in proposito?
Un po' ovunque... Probabilmente anche nell'MSDN stesso :-)
Io in tre minuti di yahoo ho trovato questo:
http://www.nightmare.com/medusa/async_sockets.html
Attenzione che esiste l'Async IO sia per i socket che per il file system :-)
(sotto windows viene anche chiamato Overlapped)
(quindi teoricamente con un singolo thread puoi gestire tutte le connessioni
che vuoi)
--- bye

 che vuoi)
Sapendo cosa cercare è ancora più semplice... Io ho usato ReadFile, Winsock
e LPOVERLAPPED come parole chiave (la funzione per leggere da un file, la
libreria per gestire le comunicazioni via socket e il nome della struttura
che si usa per l'async io (tecnicamente è un puntatore al...))
http://www.docendo.se/mspress/msp_online/samplechapter/0735615799.htm
http://www.msdn.microsoft.com/msdnmag/issues/1000/winsock/default.aspx
--- bye

Dimenticavo del dimenticavo...
Se possibile conviene usare TransmitFile e/o TransmitPacket (il primo è
disponibile da NT in poi, il secondo da XP in poi). Sono utili perchè
velocizzano ancora di più il tutto. Perchè? Semplice: mettiamo che tu deva
spedire un file via socket.
Procedimento normale:
1. Leggi un blocco di file in memoria
2. Spedisci un blocco di file via socket
3. ritorni al punto 1.
In questo approccio ci sono due problemi: tu passi dalla modalità kernel
alla modalità normale varie volte (esegui due operazioni kernel
inframmezzate da varie operazioni client, se usi l'asynch io devi gestire
due eventi, uno per il file e uno per il socket etc.) e inoltre il file
viene copiato varie volte nella memoria (ti spiego... Tu dici "leggi il
file"... Il FS legge il file nella cache... E poi te ne crea una copia per
te. Tu spedisci questa copia del pacchetto. Con i memory map elimini la
copia: il FS legge il file nella cache e te ne dà un puntatore. Tu spedisci
quello che c'è nella cache. Il problema è che sotto Windows non credo tu
possa creare una memory map asincrona, quindi le tue letture sarebbero
bloccanti. E inoltre anche se tu lo potessi fare, avresti il problema che
dovresti gestire due eventi asincroni, più due chiamate distinte al kernel.
TransmitFile risolve il problema: il SO provvede a leggere un pezzo del file
e a spedirlo. Chiaramente visto che è fatto tutto dal SO in modalità kernel,
sicuramente sarà fatto nella maniera migliore possibile. Una sola chiamata
kernel, un solo evento asincrono da gestire nel programma, di sicuro il SO
al suo interno non farà la copia inutile dei dati (infatti è scritto
nell'msdn che non la fa)...
--- bye

Grazie di tutto. Mi metto all'opera per utilizzare questa tecnica nei 
miei prossimi progetti (tempo permettendo ;P)
