Italian Sto ancora là...!

[tigrot]

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

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]

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]

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.

 

[tigrot]

Immagino che non ci siano semafori ed altri dispositivi atti ad evitare la concorrenza delle operazioni...

 

[Star-Dust]

Fai così

sub lamiasub
  dim ID_Instanza as integer
end sub

 

[LucaMs]

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.

 

[LucaMs]

Immagino che non ci siano semafori ed altri dispositivi atti ad evitare la concorrenza delle operazioni...

Non ci sono ma non penso che mi servano, nel mio caso.

 

[tigrot]

Se gestisci dati comuni, ad esempio il contatore dei thread attivi, se scali uno da due thread, teoricamente, puoi avere invece di -2 un -1 .
Con pochi thread questo non accade, ma con migliaia...

 

[Star-Dust]

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)