Newsgroup: it.comp.programmare.win32
Titolo: Funzione di callback

Salve ,
come ben saprete ,la Window Procedure in un programma windows e
definita come funzione di callback . Inoltre e' specificato che deve
essere "rientrante" . 
Qualcuno puo' spiegarmi cosa significa nel dettaglio ? 
(Forse che deve essere ricorsiva?)
grazie
~~~~~~~~~~~~~~~~~
MAINARDI Gianfranco
Burago di Molgora (MI)
Italia
Email : 
main...@rete039.it
ICQ# number : 31334916
~~~~~~~~~~~~~~~~~

essere "rientrante" . 
Vuol dire che la funzione deve essere in grado di girare contemporaneamente... a
se stessa. Se infatti la funzione contenesse del codice automodificante,
potrebbe darsi il caso che il codice modificato da una chiamata venga letto
dalla chiamata successiva prima che venga rimesso a posto generando,
evidentemente, comportamenti indesiderati. 
Il problema immagino riguardi -- in particolare -- chi si dedica alla scrittura
dei nostri amati compilatori.
Mi scuso per eventuali imprecisioni, ma non trovo l'articolo in cui ho letto
tali cose e sono andato un po' a braccio.
_mirko_
--
Knowledge is power.
"ciucciati.il.calzino" is antispam.

Se la WinProc può essere eseguita in contemporanea a se stessa, come fa il
sistema ad evitare che due messaggi vengano processati contemporaneamente?
Ad esempio, se c'è un messaggio in esecuzione (passato da DispatchMessage) e
contemporaneamente la funzione viene invocata dal SO (senza passare per la
coda)... a me sembra che questo accada producendo risultati difficili da
gestire (ad esempio usanto una tray icon, in risposta ad un'azione del mouse
sull'icona: si può cliccare infinite volte sull'icona aprendo sempre il menu
e selezionando una voce, questo mentre il programma dovrebbe essere fermo
aspettando la chiusura di un MessageBox... col risultato che lo stesso
MessageBox puà essere aperto infinite volte... o anche una dialog box)
Lorenzo

...

Di solito il problema non e' il codice automodificante (che renderebbe
comunque una funzione non rientrante) ma le risorse usate dalla funzione,
dove con risorse di intende qualunque oggetto (variabile e, perche' no,
anche il codice) utilizzato dalla procedura.
Una procedura e' rientrante se puo' essere invocata contemporaneamente da
piu' path di esecuzione.
La "rientranza" e' una proprieta di una procedurae richiesta solo in
ambiente multi-threading. Se una procedura X, chiamata da piu' thread,
utilizza un oggetto statico Y, potenzialmente piu' path di esecuzione
(thread) possono accedere contemporaneamente all'oggetto Y generando
risultati scorretti.
Un esempio banale potrebbe essere la printf(): di solito questa funzione
utilizza un buffer per la conversione di interi, float, ecc. Se il buffer
e' statico e non si prevedono metodi di sincronizzazione, due thread
potrebbero cercare di lavorare sullo stesso buffer di caratteri
contemporaneamente, producendo risultati impredicibili. La printf(), in
ambienti multi-thread, deve essere rientrante.
Per essere rientrante una procedura deve:
- usare solo oggetti locali alla procedura (allocati sullo stack), oggetti
forniti dal chiamante (la responsabilita' sulla mutua esclusione si
trasferisce al chiamante) o privati del thread corrente
- usare risorse globali attraverso dei sistemi di sincronizzazione
(semafori)
Il problema della rientranza riguarda chiunque programmi applicazioni
multi-thread.
Credo che la WinProc debba essere rientrante in quanto si potrebbero creare
piu' finestre a partire dalla strassa WNDCLASS, gestite tutte dalla stessa
WinProc. All'interno della stessa applicazione la WinProc potrebbe essere
contemporaneamente da ogni finestra. Porbabilmente il problema non si pone
se la winProc e' usata per una sola finestra (i messaggi vengono accodati
da windows e processati sequenzialmente su un singolo path di esecuzione).

[...]
Credo anch'io sia per questo motivo, infatti piu` copie di un programma
(processi) in esecuzione contemporaneamente, pur non condividendo i segmenti dei
dati condividono il codice. A questo proposito (a meno di non dichiarare
segmenti shared) rimane solo l'ipotesi del codice automodificante (?).
Ovviamente i tuoi approfondimenti sulle risorse in generale (che non ho citato)
sono basilari nel caso non si parli di WndProc e processi in particolare, ma di
thread in generale (in questo caso infatti l'ipotesi piu` "gettonata" e` quella
dei dati condivisi e non del codice automodificante).
PS: Complimenti per la chiarezza nell'esposizione.


 
Infatti mi riferivo piu' che altro alla creazione di piu' finestre dalla
stessa applicazione (processo), con un thread per finestra (e quindi una
WinProc [sempre lo stesso codice/dati] per thread.
Nel caso dei processi, il problema della condivisione dei dati non si pone
(ma potenzialmente rimane quello del codice, anche se le pagine di memoria
del codice sono read-only (ma teoricamente e' possibile modificarne gli
attributi, Windows permettendo)

 ~~~~~~~~~~~~~~~~~
La Window procedure è una funzione callback  perchè ,a differenza delle
normali funzioni viene chiamata direttamente da windows,  deve essere
rintrante ècioe non puo essere interrotta ,quindi non puoi invocare
interrupt all ' interno della stessa a meno di non usare particolari
accorgimenti (assicurare la rientranza)
ciao

ambiente multi-threading. Se una procedura X, chiamata da piu' thread,
Non e' totalmente corretto restringere agli ambienti multi-threading, spesso
e' necessario anche con funzionamento ad interruzione. In linea piu generica
e' necessario assicurare la rientranza ogni qualvolta ci puo' essere accesso
concorrente (dove per concorrente non e' necessario intenderlo contemporaneo
in termini strettamente temporali).
Ciao, Marco.