Flusso di eventi. Come controllare e rendere l'evento inattivo? (+ risolto) - pagina 2
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Yedelkin:
Di conseguenza, non è ancora chiaro quanto spesso gli eventi utente dovrebbero essere inviati in modo che non trabocchino nella coda degli eventi del terminale...
Non riesco a trovare una risposta alla domanda: in che modo un overflow della coda degli eventi influisce sulla dimensione della RAM? Se la coda degli eventi è piena, dove vanno gli eventi che hanno superato la coda? Si libera una parte della RAM, riservata a quegli eventi che sono capitati "fuori dalla storia"?
Forse le mie domande non sono terminologicamente corrette, ma (spero) catturano l'essenza del problema.
La coda è dinamica e cresce per necessità.
Ma ad un certo limite, i nuovi eventi vengono scartati perché è chiaro che non ha senso caricare ulteriormente la coda.
Capisco subito che non hai letto i miei post.
Perché non l'hai "letto"? Tu hai risolto il tuo problema, io sto cercando di risolvere il mio, di tipo diverso. Quando ho letto la discussione, non ho trovato una risposta alle mie domande.
Non hai risposto alla mia domanda principale. :/ Questo è esattamente il "vedere a colpo d'occhio" :)
La coda è dinamica e cresce per necessità.
Ma ad un certo limite, i nuovi eventi vengono scartati, perché è chiaro che non ha senso caricare ulteriormente la coda.
OK, la coda è "dinamica". Aumenta fino a un "certo" limite. Ma perché nessuno può dare una risposta a una domanda apparentemente semplice: come influisce l'overflow della coda degli eventi sulla dimensione della memoria?
Domande successive: quanta RAM è necessaria per "mantenere" una coda di eventi sovraffollata? Se "ad un certo limite, i nuovi eventi vengono scartati", viene liberata la RAM precedentemente allocata per questi eventi scartati?
Scopo delle domande: capire come il flusso di eventi dell'utente può aumentare (aumenta) la quantità di RAM consumata dal terminale.
Se la coda degli eventi è piena, dove vanno gli eventi che hanno superato la coda? Si libera una parte della RAM riservata a quegli eventi che sono "fuori dalla storia"?
Forse le mie domande non sono terminologicamente corrette, ma (spero) trasmettono l'essenza del problema.
La sezione dice Program Execution che i nuovi eventi vengono scartati quando la coda trabocca:
Il terminale client invia gli eventi che si verificano ai grafici aperti appropriati. Gli eventi possono anche essere generati dai grafici (eventi del grafico) o dai programmi mql5 (eventi personalizzati). La generazione di eventi di creazione e cancellazione di oggetti grafici in un grafico può essere abilitata o disabilitata impostando le proprietà CHART_EVENT_OBJECT_CREATE e CHART_EVENT_OBJECT_DELETE di un grafico. Ogni programma mql5 e ogni grafico ha la sua coda di eventi, dove vengono memorizzati tutti i nuovi eventi.
Il programma riceve eventi solo dal grafico su cui è in esecuzione. Tutti gli eventi sono processati uno per uno nell'ordine di ricezione. Se c'è già un evento NewTick nella coda o se questo evento è in stato di elaborazione, un nuovo evento NewTick non viene messo nella coda del programma mql5. Allo stesso modo, se la coda del programma mql5 contiene già l'evento ChartEvent o l'evento è in fase di elaborazione, un nuovo evento di questo tipo non viene messo in coda.
Le code di eventi hanno una dimensione limitata, ma sufficiente, quindi l'overflow della coda per un programma scritto correttamente è improbabile. Quando si verifica l'overflow della coda, i nuovi eventi vengono scartati senza essere accodati.
È altamente sconsigliato l'uso di cicli infiniti per elaborare gli eventi. L'unica eccezione a questa regola sono gli script che gestiscono un singolo evento Start.
Lebiblioteche non gestiscono alcun evento.
Perché non l'hai "letto"? Tu hai risolto il tuo problema, io sto cercando di risolvere il mio, di tipo diverso. Quando ho letto la discussione, non ho trovato una risposta alle mie domande.
Non hai risposto alla mia domanda principale. :/ Ho potuto sicuramente "vedere subito" :)
La tua domanda "qual è la frequenza approssimativa alla quale gli eventi utente dovrebbero essere inviati, in modo che non trabocchino nella coda".
La mia risposta nella prima pagina è "con la frequenza delle chiamate OnChartEvent".
Cioè, un evento è un OnChartEvent. Non ci dovrebbero essere più di due eventi in mezzo.
Questa è tutta la matematica.
Ancora una volta, leggete la prima pagina. Ho mostrato come evitare l'accumulo di eventi utente quando l'evento terminale viene processato al posto dell'evento utente. È così semplice.
Scopo delle domande: capire come un thread di eventi utente può aumentare (aumentare) la dimensione della RAM consumata dal terminale.
Perché? Beh, sì, è così. Il prezzo della domanda è di pochi megabyte.
Non è questo il problema, o non proprio il problema.
La sezione dice Esecuzione del programma, che...:
1. la sezione del manuale ha subito cambiamenti significativi.
1.1 Per esempio, prima era:"Il terminale client mette tutti gli eventi che si verificano in una coda comune. Così gli eventi sono processati uno dopo l'altro in ordine di arrivo. L'eccezione è l' evento NewTick. Se c'è già un tale evento nella coda o se questo evento è in corso di elaborazione, un nuovo evento NewTick non viene messo in coda".
Ora:"Il programma riceve eventi solo dal grafico su cui sta girando. Tutti gli eventi sono processati uno dopo l'altro nell'ordine in cui vengono ricevuti. Se c'è già un evento NewTick nella coda o questo evento è in stato di elaborazione, un nuovo evento NewTick non viene messo nella coda del programma mql5. Allo stesso modo, se c'è già un evento ChartEvent nella coda di mql5-program o un tale evento è in corso di elaborazione, un nuovo evento di questo tipo non viene messo in coda.
Come dice il proverbio, "Vedi la differenza". Dovresti almeno essere avvertito. :/ Questo cambiamento cambia fondamentalmente il modo in cui lavoriamo con gli eventi personalizzati.
1.2. Avanti. Il principio di scartare gli eventi è capovolto. Prima era: "La coda degli eventi ha una dimensione limitata. Quando la coda si riempie, i vecchi eventi vengono cancellati senza essere elaborati per fare spazio ai nuovi eventi in arrivo".
Ora: "Quando la coda è piena, i nuovi eventi vengono scartati senza essere accodati". Come si dice, grazie: perdiamo gli eventi utente più rilevanti.
2. La sezione citata del Manuale non risponde alle mie domande fondamentali: Come influisce l'overflow della coda degli eventi sulla dimensione della RAM? Quanta RAM è necessaria per "mantenere" una coda di eventi straripante? Se "ad un certo limite, i nuovi eventi vengono scartati", la RAM precedentemente allocata per quegli eventi scartati viene liberata?
TheXpert:
Scopo delle domande: capire come un thread di eventi utente può aumentare (aumentare) la dimensione della RAM consumata dal terminale.
Perché? Beh, sì, è così. La domanda vale diversi megabyte.
2. La sezione citata nel Manuale non risponde alle mie domande principali: Come influisce l'overflow della coda degli eventi sulla dimensione della RAM? Quanta RAM è necessaria per "mantenere" una coda di eventi che trabocca? Se "ad un certo limite, i nuovi eventi vengono scartati", la RAM precedentemente allocata per quegli eventi scartati viene liberata?
Se sorgono questi problemi, allora le cose vanno molto male. Penso che una coda di eventi traboccante sia l'ultimo posto dove cercare problemi di memoria.
Se un evento viene scartato, allora semplicemente non viene messo in coda. La memoria non cresce.