Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1

    [C#] Come faccio per Ricevere un risultato da un altro Thread

    Salve,
    nel seguente codice che ho inserito,
    vorrei ricevere la risposta di "OK" sul Metodo Start(), per gestire la condizione if(??? == "OK")

    solo che devo riceverlo dal metodo Test() che si trova su di un altro Thread.....

    come posso passare quella risposta ??

    codice:
            private void Start()
            {
                DataThread data = new DataThread("mario");
                Thread t = new Thread(new ParameterizedThreadStart(Test));
                t.Start(data);
    
                if(??? == "OK")
                {
                    MessageBox.Show("Tutto OK!");
                }
            }
    
            private void Test(object _data)
            {
                string nome = ((DataThread)_data).Nome;
    
                if (nome == "mario")
                {
                    //Voglio comunicare a: Start() che è "OK"
                    //
                    //
                }
            }
    
            class DataThread
            {
                private string m_nome = "";
    
                public DataThread(string _nome)
                {
                    m_nome = _nome;
                }
    
                public string Nome
                {
                    get { return m_nome; }
                    set { m_nome = value; }
                }
            }

  2. #2
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,481
    Due thread possono condividere una variabile.
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  3. #3
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    Ciao,
    con il thread separato stai trasformando l'esecuzione sincrona in esecuzione asincrona, quindi non avrebbe molto senso bloccare il thread principale per attendere la risposta del thread secondario. Detto questo, se mi dai una buona motivazione per farlo ti rispondo anche a questo

    nel tuo caso specifico potresti anche far fare il lavoro del messageBox nel metodo chiamato dal thread secondario (Test(object _data)), ma se non vuoi farlo li, potresti fare un metodo che chiami (sempre dal thread secondario) passando il risultato della condizione, oppure farlo attraverso delegato, condividere una variabile ecc..

    insomma se se spieghi meglio cosa devi fare in realtà... se è veramente quello il codice da eseguire allora basta la prima: metti il messageBox dentro Test(object _data).



    EDIT :
    sono arrivato tardi

  4. #4
    1) il metodo "Test(object _data)" fa una chiamata di tipo HttpWebRequest() ad un Provider.

    2) il Provider impiega circa 10/20 sec. per la risposta, la quale è una stringa "Eseguito" oppure "Fallito".

    3) il prossimo Thread con la successiva chiamata HttpWebRequest(), deve partire solo dopo la risposta

    la variabible string responseFromServer, è quella che dovrebbe valorizzarsi con la risposta del Provider.


    in realta il metodo Start() ha in ciclo al suo interno:

    codice:
            private void Start()
            {
                string responseFromServer = "";
    
                for(int i = 0; i <= 10000; i++)
                {
                    if (i == 0) responseFromServer = "OK";
    
                    if(responseFromServer == "OK")
                    {
                        DataThread data = new DataThread("mario");
                        Thread t = new Thread(new ParameterizedThreadStart(Test));
                        t.Start(data);
                    }
                }
            }

  5. #5
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    quindi mi pare di capire che il fatto di volere il thread separato sia una questione più che altro estetica, per evitare il "congelamento" del form durante l'attesa del completamento delle richieste. Quindi comunque le richieste devono essere eseguite in maniera "sincronizzata", ovvero una dietro l'altra. Ho capito bene? Se si allora non mettere il ciclo in start, mettilo dentro Test, in questo modo non rimane bloccato il form e le richieste web vengono gestite tutte in maniera sequenziale in modo sincrono dentro il thread secondario. A limite se vuoi un feedback dopo le richieste web, segui comunque i consigli dati in precedenza da me e da oregon.

  6. #6
    Quanto mi dici è correttissimo, se inviassi solo ad un Provider.

    Non ho solo un Provider, ne ho 15 a mia disposizione.

    Se io volessi fare partire 15 Thread contemporaneamente per potere soddisfare 15 Richieste...? ...e poi successivamente le altre 15 ?? ...e cosi via...!!

    una sola richiesta in coda all'altra è molto piu' lenta che 15 in coda a 15 !!

    Sbaglio ?

  7. #7
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    Originariamente inviato da w_t
    Quanto mi dici è correttissimo, se inviassi solo ad un Provider.

    Non ho solo un Provider, ne ho 15 a mia disposizione.

    Se io volessi fare partire 15 Thread contemporaneamente per potere soddisfare 15 Richieste...? ...e poi successivamente le altre 15 ?? ...e cosi via...!!

    una sola richiesta in coda all'altra è molto piu' lenta che 15 in coda a 15 !!

    Sbaglio ?
    questo non l'avevi specificato, sopratutto, non mi pare coerente con ciò che hai lasciato intendere prima (o che comunque potrei aver frainteso io) perchè se io ho la necessità di aspettare che la risposta debba essere positiva o negativa per avviare le richieste successive, anche se ho tanti thread comunque devo farli attendere, ergo, non sono necessari

    caso diverso è se devi creare tanti "blocchi" di richieste consecutive, ma ogni blocco non è legato ad altri (non deve attendere la risposta alle richieste di altri blocchi), ma comunque, all'interno di ogni blocco la sincronia è necessaria (da quello che mi pare di capire cercando una logica). In questo caso allora dovresti avere un potenziale ciclo che avvia i thread (dei blocchi di richieste) che a loro volta avviano delle richieste sincrone su altri thread.

    per capirci meglio (nell'ultimo caso) :

    codice:
    thread form 
           thread secondario
                  thread blocco
                         thread sincrono req 1 ->  req 2 -> req 2 -> ecc.
                  thread blocco
                         thread sincrono req 1 ->  req 2 -> req 2 -> ecc.
                  thread blocco
                         thread sincrono req 1 ->  req 2 -> req 2 -> ecc.

  8. #8
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,481
    [opinione personale]
    Il fatto è che stai tentando di mettere in piedi tutto l' "accrocchio" di "sender di sms" distribuiti su n sistemi (con n IP diversi per l'invio gratuito) e il "gestore" di tutte le richieste verso i sender.

    Molto, ma molto più semplice è acquistare il pacchetto di sms ed evitare tutto questo sviluppo (che ha un costo sicuramente superiore).
    [/opinione personale]
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  9. #9
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    Originariamente inviato da oregon
    [opinione personale]
    Il fatto è che stai tentando di mettere in piedi tutto l' "accrocchio" di "sender di sms" distribuiti su n sistemi (con n IP diversi per l'invio gratuito) e il "gestore" di tutte le richieste verso i sender.

    Molto, ma molto più semplice è acquistare il pacchetto di sms ed evitare tutto questo sviluppo (che ha un costo sicuramente superiore).
    [/opinione personale]


    non avevo legato le cose

    w_t lascia perdere , come dice oregon NON CONVIENE, ne economicamente, ne come tempi, ne come mole di lavoro, ma sopratutto come fedina penale...

    ammesso che riesci a raggirarli (perchè comunque sai che potrebbero avere altri sistemi che ancora non conosci o non sai che ci sono contro quello che vuoi fare tu?!?), pensi che poi non si accorgano mai? prima o poi si accorgeranno e tu e i tuoi "colleghi" finirete nei guai... probabilmente costretti a pagare migliaia o centinaia di migliaia di sms (dipende da quanto tempo durate), trascinati in tribunale non avreste speranze, è un raggiro e a giudicare da tutte le tracce lasciate in giro (richieste sui forum ecc.) non sarebbe troppo difficile da dimostrare.

    come oregon aggiungo che è una mia opinione personale, ma se fossi in te non lo farei.

  10. #10
    Originariamente inviato da oregon
    [opinione personale]
    Il fatto è che stai tentando di mettere in piedi tutto l' "accrocchio" di "sender di sms" distribuiti su n sistemi (con n IP diversi per l'invio gratuito) e il "gestore" di tutte le richieste verso i sender.

    Molto, ma molto più semplice è acquistare il pacchetto di sms ed evitare tutto questo sviluppo (che ha un costo sicuramente superiore).
    [/opinione personale]
    1) non è un accrocchio, l'interfaccia è venuta bene, il codice è pulito e breve, nella dinamica mancava solo la gestione della risposta de Provider.

    2) per gli IP ho trovato la soluzione http://msdn.microsoft.com/en-us/libr...est.proxy.aspx

    3) per la spesa è nulla, lo sviluppo nel tempo extra lavoro.

    4) Se acquisto gli SMS non anno ragione di esistere questi siti

    5) Legalmente dove stà l'infrazione ???

    Invio da un IP, verso un Provider, un SMS ogni 3min.
    Solo che dato che ho trovato 30 Provider diversi e Gratuiti, contemporaneamente posso inviare 25sms ogni 3min.

    Devo fare una campagna pubblicitaria su 10.000 contatti ogni 2/3 mesi, i quali contatti anno aderito a ricevere gli SMS.

    Ora mi dite che se apro un sito manualmente non invio un SMS ogni 3 min ??

    50.000/25 = 333sms * Provider ogni 3 mesi, vi sembra una infrazione di qualche codice che non credo esista neppure ???

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.