Newsgroup: it.comp.programmare.win32
Titolo: Usare un puntatore mappato dopo che il mapping e` stato chiuso

Supponiamo di creare un file mapping con CreateFileMapping() e di mappare
una vista su di esso con MapViewOfFile(). Supponiamo poi in seguito di
chiudere il file mapping, ma di non chiamare UnmapViewOfFile() per la vista.
In questo caso posso continuare comunque a usare la vista o devo considerare
il puntatore invalido?
I limitati esperimenti che ho fatto sinora (pero` soltanto sotto a Windows
2000) mi fanno pensare che funzioni lo stesso, ma dato che non ho trovato
alcun riferimento su MSDN vorrei essere certo che sia una procedura
ortodossa.
Grazie,
-- 
Lorenzo

In questo caso posso continuare comunque a usare la vista o >devo
considerare il puntatore invalido?
Secondo me il puntatore resta valido, visto che chiudi solo l'HANDLE del
file e la vista non è altro che un puntatore a un buffer di memoria. Però,
senza essere sicuri al 100% , non mi avventurerei. Perché ti serve ?
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ti serve ?
Perche` devo ingrandire il file in un secondo tempo, e cosi` facendo il file
mapping non funzionerebbe per la porzione di file aggiunta. Nel contempo
pero` le "vecchie" viste devono rimanere valide e nello stesso indirizzo
(quindi non posso chiuderle e riaprirle tutte, perche` MapViewOfFileEx() non
mi da` la certezza di mappare all'indirizzo che gli dico io).
L'alternativa sarebbe quella di aprire un file mapping diverso per ciascuna
vista e tenerli tutti aperti, pero` non so quale delle due tecniche sia piu`
corretta.
-- 
Lorenzo

Perche` devo ingrandire il file in un secondo tempo, e cosi` >facendo il
file mapping non funzionerebbe per la porzione di >file aggiunta.
Quindi devi aprirlo ogni volta...
Se ti interessa tenere i vari buffer, potresti di volta in volta copiarli in
un buffer da te aperto. Poi deallochi la vista, chiudi la mappa.. e cominci
da capo.. aprendole di nuovo entrambe.


 comunque a usare la vista o devo considerare il puntatore invalido?
"CreateFileMapping
[...]
To fully close a file mapping object, an application must unmap all 
mapped views of the file mapping object by calling UnmapViewOfFile, and 
close the file mapping object handle by calling CloseHandle. The order 
in which these functions are called does not matter. The call to 
UnmapViewOfFile is necessary because mapped views of a file mapping 
object maintain internal open handles to the object, and a file mapping 
object will not close until all open handles to it are closed.
[...]"
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 closed.
Certo, l'avevo letto, ma questo non risponde alla mia domanda. E` un po'
come dire che per smontare le ruote di un'automobile puoi partire prima da
quelle davanti o da quelle dietro indifferentemente; cio` non significa che
puoi continuare ad andare in giro con soltanto due ruote.
-- 
Lorenzo

 Certo, l'avevo letto, ma questo non risponde alla mia domanda
oh, peccato. Continua pure a tentativi


 oh, peccato. Continua pure a tentativi
Purtroppo si`, almeno finche` qualcuno non sara` in grado di
rispondermi.
Perche`, sei ancora convinta che la tua risposta fosse illuminante?
-- 
Lorenzo

Perche`, sei ancora convinta che la tua risposta fosse illuminante?
   Se non capisci bene l'inglese, sei giustificato. :)
-- 
S.L.

 Se non capisci bene l'inglese, sei giustificato. :)
Io lo capisco, e voi?
Quel passaggio di MSDN dice solamente che per chiudere un file mapping
bisogna chiudere sia l'handle del file mapping che tutte le viste
mappate su di esso. Aggiunge che non importa l'ordine con cui si
chiudono l'uno e le altre. Afferma infine che vengono mantenuti degli
"handle interni" alle viste mappate. Non precisa *affatto* se le viste
possano essere ancora utilizzate o meno dopo aver chiuso l'handle del
file mapping.
-- 
Lorenzo

"handle interni" alle viste mappate.
   Non e` esatto: "mapped views of a file mapping object maintain
internal open handles to the object (*)"
(*) Mantengono handle del file mapping object. Se mantengono quegli
handle il file mapping object e` ancora aperto ("and a file mapping
object will not close until all open handles to it are closed"). Tu
hai chiuso solo il tuo handle. Ci sono ancora tanti handle aperti
quante sono le viste che hai mappato. La mappatura continua a
funzionare, perche` il file mapping object e` ancora aperto. E` ancora
aperto perche` l'unico handle che e` stato chiuso e` il tuo.
   Ma poi, fai un po' tu. Saluti.
-- 
S.L.

 closed").
Ci sono altri casi in cui un handle rimane aperto ma di fatto l'oggetto a
cui si riferisce ha cambiato stato e/o comportamento. Ad esempio l'handle di
un processo e` valido anche quando esso e` terminato, e viceversa chiudendo
l'handle di un processo esso non termina. In quel caso e` piu` intuitivo
capire come funzionano le cose, anche perche` MSDN lo indica in modo
esplicito; in questo caso invece la questione mi sembra decisamente piu`
sottile, e specificarlo non avrebbe fatto male.
MSDN non dice esplicitamente se si possa continuare a *usare* le viste di un
file mapping anche dopo aver chiuso il "mio" handle, per cui ho chiesto un
vostro parere. Me l'avete dato, vi ringrazio, per inciso io ero dello stesso
avviso; cio` che mi infastidisce e` che sia stato usato un tono saccente e
spocchioso, come se si trattasse di un fatto incontestabile.
-- 
Lorenzo

 meno dopo aver chiuso l'handle del file mapping.
non deve precisarlo. Finchè ci sono riferimenti, impliciti o espliciti, 
una risorsa continua a esistere. Questo vale sempre


 spocchioso, come se si trattasse di un fatto incontestabile.
a me sembra lapalissiano la conclusione che essendo refcounted l'handle (
te lo dice msdn) e che ogni vista aumenti il refcount ( te lo dice msdn ) 
tu possa usare la vista dopo aver chiuso l'handle al file mapping.. se poi
ritieni che anche le cose evidenti vadano specificate...
riguardo la spocchiosità.. onestamente avendo letto la discussione da
fuori, il tono saccente sembra provenire dal tuo post..
dopotutto tu "chiedi pareri", generalmente gli altri quando non sanno che
pesci pigliare "chiedono aiuto".
sarà che sto invecchiando.
sbirish ed i risotti alle ortiche.  

 sarà che sto invecchiando.
Non e` una questione di invecchiare, il fatto e` che periodicamente su
questo NG scoppia una specie di epidemia (chissa`, magari serve per alzare
le difese immunitarie) per cui anziche` dare semplicemente il proprio
contributo, la gente ama rispondere in modo sgradevole e/o con un'aria di
sufficienza assai fuori luogo. Non mi riferisco soltanto al mio thread,
basta leggerne un paio della scorsa settimana.
Tutto cio` lo dico non solo perche` ho a cuore la "salute" di questo
newsgroup, ma anche per un motivo molto egoistico: dato che fare polemica
piace parecchio anche a me, e che devo trattenermi per non fare del last
word freaking, queste ondate di spocchia a buon mercato mi fanno perdere
parecchio tempo, perche` non riesco a esimermi dal replicare (inutilmente,
sono il primo ad ammetterlo).
-- 
Lorenzo

 continuare comunque ad accedere alle regioni lockate, giusto?
guarda che l'esempio non calza affatto, gli "handle" qui sono diversi,
nell'altro caso l'handle refcounted è lo stesso. 
poi se vuoi arrampicarti sugli specchi...
sbirish.

object will not close until all open handles to it are closed.
   Ora, non mi aspetto che tu lo riconosca, ma l'atteggiamento di
sufficienza l'hai dimostrato tu, affermando prima "questo non risponde
alla mia domanda" e successivamente "Perche`, sei ancora convinta che
la tua risposta fosse illuminante?".
   A questo punto esprimo meglio quello che avevo gia` scritto: se tu
non capissi bene l'inglese, saresti giustificato. Poiche` invece lo
capisci, e ti senti addirittura offeso da chi ipotizza il contrario,
la conclusione, per me, e` una sola: non dedichi la giusta attenzione
ai post di chi ti risponde, e esprimi giudizi con superficialita`.
   Saluti, e a questo punto anche *plonk*.
-- 
S.L.