AppDomain.GetCurrentThreadID vs Thread.ManagedThreadID pour les appels API Windows?

Je suis en train de créer un crochet pour surveiller la position actuelle du curseur de la souris. Rien d'important, j'ai juste besoin de compter quelques pixels lors de la conception de l'interface et je voulais savoir comment créer un crochet, alors j'ai décidé d'aller pour une difficulté plutôt d'une façon saine.

J'ai trouvé un exemple de code qui déclare la fonction suivante:

 <DllImport("User32.dll", CharSet:=CharSet.Auto, _
 CallingConvention:=CallingConvention.StdCall)> _
 Public Overloads Shared Function SetWindowsHookEx _
      (ByVal idHook As Integer, ByVal HookProc As CallBack, _
       ByVal hInstance As IntPtr, ByVal wParam As Integer) As Integer
End Function

Lorsque la fonction est appelée, le code suivant est utilisé:

        hHook = SetWindowsHookEx(WH_MOUSE, _
                                 hookproc, _
                                 IntPtr.Zero, _
                                 AppDomain.GetCurrentThreadId())

Mais Appdomain.GetCurrentThreadID génère l'avertissement: ""Public Partagé Fonction GetCurrentThreadId() as Integer' est obsolète: 'domaine d'application.GetCurrentThreadId a été abandonné car il ne fournit pas un stable Id lors de la gestion des threads en cours d'exécution sur les fibres (aka léger threads). Pour obtenir un identifiant stable pour une gestion thread, utilisez la propriété ManagedThreadId sur le Fil."

J'ai essayé d'utiliser ManagedThreadID, mais qui ne fonctionne pas. L'ID de thread retourné semble être la logique ID du thread, car elle fonctionne dans la .net, plutôt que le thread Win32 identificateur.

L'appel de la fonction ith domaine d'application.GetCurrentThreadID fonctionne, mais je voudrais vraiment avoir un "identifiant stable" pour mon fils.

Quelqu'un peut m'expliquer s'il est possible d'utiliser ManagedThreadID dans ce contexte (je suppose que non) et, si non, les choses que je dois éviter pour arrêter l'AppDomain.CurrentThreadID de devenir "instable"?

Acclamations

source d'informationauteur Frosty840 | 2009-04-21

14

Il n'est pas possible d'utiliser ManagedThreadId dans ce contexte. C'est complètement géré concept et n'a pas de véritable représentation dans le monde indigène. Par conséquent, il ne ferait aucun sens de l'API vous êtes de passage.

La raison ManagedThreadId existe, c'est parce qu'il n'est pas nécessairement un mappage 1-1 entre un natif et géré fil. Le CLR est libre d'utiliser plusieurs threads natifs pour exécuter un seul thread géré tant que le thread natif est compatible avec l'un c'est qu'il remplace. Il ne peut pas, par exemple, être dans un autre COM appartement.

À certains égards, vous êtes un peu coincé ici. Autant que je sache, il n'existe aucun moyen de garantir à 100% que vous aurez le même thread natif pour un thread géré. Vous pouvez obtenir un très haut niveau de garantie mais si vous êtes par exemple l'exécution d'un WinForms ou WPF application et l'appel à du code natif se produit sur le thread de l'INTERFACE utilisateur. La raison étant que ces deux cadres de l'INTERFACE utilisateur vivent dans des STA appartements qui le rend très dur (même si c'est possible) pour le CLR pour passer sous vous.

Version courte: Si vous êtes dans un WinForms ou WPF application et l'exécution de ce sur le thread de l'INTERFACE utilisateur, vous pouvez supposer un degré raisonnable de stabilité pour cet identificateur.
3

Pour les futurs lecteurs:
Il y a aussi le Système.Le filetage.Fil de discussion.BeginThreadAffinity() /EndThreadAffinity fonctions (), qui prétend arrêter la VM à partir de la commutation entre les différents threads. Je ne crois pas que ces de garantir la stabilité, mais je pense qu'ils sont plus susceptibles d'être stable.
3

Vous pouvez utiliser:
```
using System.Diagnostics;
Process.GetCurrentProcess().Threads[0].Id
```
au lieu de

AppDomain.GetCurrentThreadId()

Le problème est de trouver le nombre exact de le thread si vous avez plus de threads que le thread principal 0 en cours d'exécution.

var thread = Process.GetCurrentProcess().Threads.OfType<ProcessThread>().
    SingleOrDefault(x => x.ThreadState == ThreadState.Running);

if (thread != null)
{
    // do stuff here
}

0

utilisation:

[DllImport("kernel32.dll")]
static extern uint GetCurrentThreadId();

Vous devez vous connecter pour publier un commentaire.