Italian Sto ancora là...!

tigrot

Well-Known Member
Licensed User
Longtime User
Per dati intendo i campi definiti nel pgm. praticamente si definiscono nello stack(definendoli nelle sub) che è proprio di ogni thread. Se definisci in una thread un campo con
B4X:
sub lamiasub
dim n as integer
end sub
avrai che esiste un n differente per ogni thread.
Se devo leggere uno stream su TCP/IP mi fermo in una waitforevent(può attendere un complesso di eventi, come tempo o dati ricevuti). Quando si verifica una condizione vengo riavviato e leggo che condizione mi ha attivato. Non so come funziona in B4A o B4J, ma visto che tutti i linguaggi che lo permettono funzionano allo stesso modo immagino che se non è zuppa è panbagnato anche in questi linguaggi. Ora ci guardo...
 

LucaMs

Expert
Licensed User
Longtime User
Tecnica multitask. Immagina che il tuo programma possa eseguire contemporaneamente in diversi statements. Il problema è la rientranza dei dati. Una task ti distrugge i dati dell'altra, se non architettata ad hoc. Ne ho scritto una di applicazioni anni fa, ma in C++.
So cosa sia la programmazione multi-thread e la difficoltà nel condividere dati, ma quegli "oggetti", background workers, sembrano essere cose particolari.

Inoltre, leggendo i primi 3 post, si nota che sia necessario conoscere a priori il numero di oggetti necessari e non è il mio caso.
Ho chiesto ad Erel, vedremo cosa risponderà.
 

tigrot

Well-Known Member
Licensed User
Longtime User
In pratica sembra che attivi una classe, ma non mi sembra che ci sia una preattivazione. Se in una thread(la main?) attendi le connessioni ad ognuna puoi attivare la classe che gestisce il messaggio e terminarla se necessario. avrai un numero di thread addizionali pari al numero di utenti connessi + la main.
 

Star-Dust

Expert
Licensed User
Fai così
B4X:
sub lamiasub
  dim ID_Instanza as integer
end sub
:p:p:p
 

LucaMs

Expert
Licensed User
Longtime User
C'è questa affermazione di Erel che mi fa capire / pensare che io non possa utilizzare quegli "oggetti":

It must be set before the call to Server.Start.

Quindi tu devi conoscere fin dall'inizio quanti dovranno essere i task, mentre a me serve appunto poterli creare a runtime.
 

Star-Dust

Expert
Licensed User
Più che un contatore pensavo a un identificativo. Ho fatto qualcosa di simile in un server creato con B4A per un App per la ristorazione (è una mia fissa l'app per la ristorazione)
 
Top