Newsgroup: it.comp.programmare.win32
Titolo: [Memoria a runtime, processi] Due parole per chiarire

Sottopongo di nuovo a questo NG una questione relativa a Win32 e le sue
API.
A. Memoria a runtime
Non riesco a capire bene quando e` conveniente utilizzare le API della
famiglia Virtual...() (es. VirtualAlloc(), ecc) rispetto a quelle della
famiglia Heap...() (es. HeapAlloc()). Nel primo caso si possono
manipolare attributi per evitare che la memoria impegnata sia paginata
dal sistema (si recupera in efficenza), ma poi?
Inoltre, e` veramente 'vero' che le obsolete GlobalLock() ecc.. sono
sostituite dalle API della famiglia Heap..()? Molto codice a 32 bit,
anche Ms, le usa ancora massicciamente, quindi mi viene qualche
dubbio...
B. Id di processi e thread
Qualcuno potrebbe commentare in maniera definitiva il senso d'essere di:
- istanza di un processo-thread (l'hinstance restituito dal SO)
- PID del processo (TID del thread): se l'id. di istanza e` univoco,
perche` serve anche un PID-TID?
- hmodule (quello delle DLL)
Grazie in anticipo
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 - hmodule (quello delle DLL)
HINSTANCE e HMODULE sono lo stesso, identico tipo in Win32 (vi era
una distinzione in Win16, credo) e corrispondono all'indirizzo virtuale
di base in cui un certo modulo (indifferentemente EXE o DLL) e` stato
caricato per un certo processo.  Non sono dunque affatto univoci a
livello di sistema, ma solo in un dato momento per un dato processo
(poiche` ogni processo ha il suo spazio di indirizzi).
Incidentalmente, non vi e` nessun HINSTANCE ne` HMODULE associato
a un thread; essi sono associati ai moduli (DLL o EXE), quindi anche
dire "hinstance di un processo" e` un uso leggermente improprio (si
intende presumibilmente la HINSTANCE dell'EXE del processo).
Le HANDLE degli oggetti di kernel (compresi thread e processi -- le
HINSTANCE sono invece tutt'altra cosa) rappresentano ciascuna una
"vista" di un oggetto di kernel come posseduta da un certo processo
in un dato momento.  Non sono necessariamente comunicabili fra
processi separati.  I *NOMI* o *IDENTIFICATORI* degli oggetti di
kernel (nomi che sono stringhe per vari tipi di oggetto, come i mutex
ecc, ma sono invece identificatori numerici per thread e processi)
svolgono dunque un ruolo diverso da quello delle handle, cioe` quello
di identificare l'oggetto di kernel in modo fra l'altro anche comunicabile
incondizionatamente fra processi diversi.
Alex

 (poiche` ogni processo ha il suo spazio di indirizzi).
[taglio]
l'HINSTANCE 'ceduto' dal SO al processo rimane univoco per tutta la
vita del processo, vero? se caricassi un nuovo processo a partire dallo
stesso .EXE, il SO creerebbe un nuovo valore per l'HINSTANCE del nuovo
processo, anch'esso univoco per tutta la vita del nuovo processo; ma
non succede la stessa cosa per i relativi PID? (cioč creazione di due
PID univoci e validi fino al termine dei relativi processi). Mi
chiedevo, allora, perchč il SO ha l'esigenza di creare diversi
identificativi con simile 'destino tecnico'?
Mi si perdoni la pedanteria, ma quando mi ritrovo a spiegare i due
concetti, non riesco a mia volta a fornirne spiegazioni convincenti.


 - hmodule (quello delle DLL)
E` come hInstance. E` l'indirizzo di base di caricamento del modulo (anche se
tu "non dovresti saperlo", nel senso che deve essere considerato un handle
privo di senso e non un indirizzo).
--
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

 suo spazio di indirizzamento.
Naturalmente ero al corrente che il PID-TID fosse un oggetto di sistema
(e` una nozione comune a tutti i SO multiprogrammati); dopo cio` che
hai detto mi rendo conto della ragione per cui esiste ANCHE l'HINSTANCE.
Visto che siamo in argomento:
e` vero che l'exe su disco serve al SO mentre un suo processo e`
caricato, come supporto per la paginazione (cioe` il SO recupera
dall'exe le pagine da ricaricare in memoria dopo le eventuali revoche
avvenute al runtime). E' quindi per questo motivo che l'exe e`
'bloccato' durante l'esecuzione?


 identificativi con simile 'destino tecnico'?
Il PID e`, si`, univoco globalmente.  HINSTANCE, come ho gia`
spiegato, NO, e` univoco solo entro un dato spazio d'indirizzi
(quindi, entro un dato processo); quindi serve a distinguere i
vari moduli dello stesso processo, ma non serve a nulla fra due
processi diversi e separati (o anche EGUALI -- cioe` creati dallo
stesso EXE -- ma *comunque* separati -- come spazi d'indirizzi).
Alex

 'bloccato' durante l'esecuzione?
Esatto.  Identiche considerazioni si applicano d'altronde a
tutti i moduli, cioe` non e` che l'EXE sia minimamente diverso
dalle DLL da questo punto di vista (e la maggior parte
degli altri:-).
Alex

Grazie per la tempestivita` e la completezza delle risposte.


 'bloccato' durante l'esecuzione?
Esatto. Si utilizza una tecnica di "memory file mapping" molto simile a quella
che puoi ottenere con le API CreateFileMapping() e amici.
