nblog

Uzasadnienia nie znam, ale właśnie pracuję nad częścią aplikacji wielojęzycznej i wątkami :)

Dzięki za tip :)

Z drugiej strony wyobraźmy sobie sytuację, w której wątek przy tworzeniu byłby inicjalizowany ustawieniami wątku, powiedzmy, "rodzica" (co jest lekkim semantycznym nadużyciem, gdyż wszystkie wątki w CLR są równorzędne). Problem z pulą wątków byłby nadal nierozwiązany, gdyż mogłaby ona utrzymywać przy życiu wątki utworzone wcześniej, nawet z poziomu innych wątków, i delegować je do wykonania nowych zadań.

Co do rozwiązania problemu, proponuję następujące podejście:

public static class ThreadExtensions

{

  public static WaitCallback CreateCallback(this Thread thread, WaitCallback callback)

  {

     return CreateCallback(thread, callback, thread.CurrentCulture, thread.CurrentUICulture);

  }

  public static WaitCallback CreateCallback(this Thread thread, WaitCallback callback, CultureInfo culture, CultureInfo uiCulture)

  {

     if (thread == null) {

        throw new ArgumentNullException("thread");

     }

     if (callback == null) {

        throw new ArgumentNullException("callback");

     }

     return (object state) =>

     {

        CultureInfo originalCulture = Thread.CurrentThread.CurrentCulture;

        CultureInfo originalUICulture = Thread.CurrentThread.CurrentUICulture;

        SetThreadCulture(culture, uiCulture);

        callback(state);

        SetThreadCulture(originalCulture, originalUICulture);

     };

  }

  private static void SetThreadCulture(CultureInfo culture, CultureInfo uiCulture)

  {

     Thread.CurrentThread.CurrentCulture = culture;

     Thread.CurrentThread.CurrentUICulture = uiCulture;

  }

}

Zadanie do wykonania w wątku z puli możemy teraz zlecić w ten sposób:

private void Action(object state)

{

  // Zrób coś.

  ...

}

...

ThreadPool.QueueUserWorkItem(Thread.CurrentThread.CreateCallback(Action));

W C# 2.0 można z powodzeniem użyć tego samego podejścia, rezygnując wyłącznie ze składniowych smaczków:

public static class WaitCallbackUtility

{

  public static WaitCallback CreateCallback(Thread thread, WaitCallback callback)

  {

     if (thread == null) {

        throw new ArgumentNullException("thread");

     }

     return CreateCallback(thread, callback, thread.CurrentCulture, thread.CurrentUICulture);

  }

  public static WaitCallback CreateCallback(WaitCallback callback, CultureInfo culture, CultureInfo uiCulture)

  {

     if (callback == null) {

        throw new ArgumentNullException("callback");

     }

     return delegate (object state)

     {

        CultureInfo originalCulture = Thread.CurrentThread.CurrentCulture;

        CultureInfo originalUICulture = Thread.CurrentThread.CurrentUICulture;

        SetThreadCulture(culture, uiCulture);

        callback(state);

        SetThreadCulture(originalCulture, originalUICulture);

     };

  }

  private static void SetThreadCulture(CultureInfo culture, CultureInfo uiCulture)

  {

     Thread.CurrentThread.CurrentCulture = culture;

     Thread.CurrentThread.CurrentUICulture = uiCulture;

  }

}

...

private void Action(object state)

{

  // Zrób coś.

  ...

}

...

ThreadPool.QueueUserWorkItem(WaitCallbackUtility.CreateCallback(Thread.CurrentThread, Action));

Metody rozszerzające oczywiście można przeciążać, lecz klasa ThreadPool jest statyczna, więc nie bardzo możemy wykorzystać ten mechanizm.

Z tego co pamietam to nie wszystkie watki sa rownorzedne bo dziela sie przynajmniej ba glowne i poboczne/tla (Foreground, Background). I ich obsluga jest czasami inna.

Nie wiedzialem o takim zachowaniu, myslalem ze glowny/poczatkowy/pierwszy watek rzeczywiscie przekaze CultureInfo. Ale zerkajac reflectorem okazje sie ze jak sie nie ustawi to ustanienia "defaultowe" sa brane...

Mówisz o klasyfikacji wątków, mi zaś chodziło o relacje między nimi. Konkretnie miałem na myśli to, że niezależnie w jakich warunkach tworzone są wątki, nie ma między nimi żadnej hierarchicznej zależności typu rodzic-dziecko.

Jeszcze jeden haczyk:

class Test

{

static void ShowCulture()

{

Console.WriteLine("Thread ID={0}; Culture={1}", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.CurrentCulture.Name);

}

static void Main()

{

ThreadStart showCulture = ShowCulture;

Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo("fr-FR");

Console.WriteLine("Main Thread ID=" + Thread.CurrentThread.ManagedThreadId);

showCulture.Invoke();

showCulture.EndInvoke(showCulture.BeginInvoke(null, null));

}

}

Przykład pokazuje, że zależnie od tego, jak wywołaliśmy delegat - synchronicznie czy asynchronicznie - w ciele metody otrzymamy inne ustawienia kulturowe. Zachowanie takie wynika z tego, że pod maską BeginInvoke korzysta z puli wątków. Jest to o tyle kłopotliwe, że mechanizm asynchronicznych delegatów często wykorzystywany jest w .NET niejawnie, np. przez komponent BackgroundWorker.

Przepraszam za rozjechany kod, ale w edytorze komentarzy naprawdę ciężko nad tym zapanować. Jeszcze raz:

class Test

{

  static void ShowCulture()

  {

     Console.WriteLine("Thread ID={0}; Culture={1}", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.CurrentCulture.Name);

  }

  static void Main()

  {

     ThreadStart showCulture = ShowCulture;

     Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo("fr-FR");

     Console.WriteLine("Main Thread ID=" + Thread.CurrentThread.ManagedThreadId);

     showCulture.Invoke();

     showCulture.EndInvoke(showCulture.BeginInvoke(null, null));

  }

}