Synkronisering med GUI-tråden

[abcd423417984]

Hei

 

Jeg driver å lager et internt mikrobibliotek for noen nettverksoperasjoner som skal oppdatere et GUI. I den forbindelse må jeg kjøre noen blokkerende kall for å vente på data fra nettverket. At biblioteket selv kjører opp en egen tråd er forsåvidt ikke noe problem, men her begynner synkroniserings-helvete.

 

Det jeg ønsker er at biblioteket selv sender callbacks (har opprettet delegater og events i biblioteket) på programmets gui-tråd. Slik at når eventene faktisk blir kjørt så skjer dette i Windows.Forms sin GUI-tråd helt uavhengig av hvilke komponenter som eksisterer. På den måten kan utvikleren som benytter biblioteket slippe å tenke på tråder osv når han dytter EventArg data inn i GUI'et. I Java kunne dette løses relativt enkelt ved hjelp av SwingUtils.invokeLater(). Noen som har en god måte å løse dette på ?

 

Videre er jeg litt usikker på funksjons-kall MOT biblioteket fra en annen tråd. F.eks. hvis man skal ha en knapp for å avslutte hele greia eller sende data må jo dette f.eks. operere mot Socket objektet...Dette objektet er også i bruk av den interne tråden. Noen tanker om dette?

 

Begge disse spørsmålene er ting jeg har lurt på i flere måneder (for personlige prosjekter) uten å finne noe svar så det kunne vært artig å fått svar på dette en gang for alle.

 

Dette var så mye enklere før man fikk GUI og slapp å tenke på at blokkerende kall fikk GUI-et til å henge seg

Endret 23. juni 2007 av invictus

[Manfred]

i det du starter tråden til biblioteket, kan du ikke da beholde en referanse til dette objektet? Evt til en boolsk verdi, funksjon eller lignende i biblioteket som stopper socketen?

[abcd423417984]

i det du starter tråden til biblioteket, kan du ikke da beholde en referanse til dette objektet? Evt til en boolsk verdi, funksjon eller lignende i biblioteket som stopper socketen?

8929156[/snapback]

 

Det kan godt hende, men hvordan vil det hjelpe meg?

[GeirGrusom]

Vel nå skumleste jeg igjennom posten din, men etter det jeg kan se, er svaret på det første spørsmålet Control.Invoke

[abcd423417984]

Vel nå skumleste jeg igjennom posten din, men etter det jeg kan se, er svaret på det første spørsmålet Control.Invoke

8929786[/snapback]

 

Var å referere til et bestemt komponent jeg ville unngå...men snakker om flaks for meg: en artikkel om nettopp dette problemet dukket for kort tid siden opp på codeproject:

 

http://www.codeproject.com/csharp/invoke_other_way.asp

 

Problemet er dermed løst

 

 

Lurer fremdeles på det andre da men