exécuter le code dans le contexte du fil principal (Lazarus)

Question

Je dois exécuter du code dans le contexte du fil principal. J'utilise Lazarus + FPC. Je reçois un événement à partir d'un fil à l'intérieur d'une DLL (bibliothèque partagée si sur linux) et ma fonction de rappel est appelée. Notez que cette fonction n'est pas membre d'une classe, mais une fonction traditionnelle autonome avec une directive « cdecl » ci-joint.

Je dois TRIGER un gestionnaire d'événements de propriété pour chaque lui correspondant message que je reçois. Et ces événements doivent être transmis dans le cadre du fil principal. Je connais deux de ces solutions:

1. PostMessage
2. Application.QueueAsyncCall

La première est ok, mais il faut une poignée de fenêtre. Et puisque c'est un code bibliothèque aucune poignée est disponible. AllocateHWnd est pas une option car il n'est pas multi-plateforme. Je sais que je peux créer une forme factice mais c'est une très mauvaise solution

Le second fonctionne bien, mais j'ai un problème, que l'appel n'est pas traitée jusqu'à ce que je déplace une souris à l'intérieur par exemple l'application. Peut-être que je fais quelque chose de mal, je ne sais pas. I est comme mon appel est en cours de traitement que lorsque le message de traitement des coups de pied. Mais cela peut être une longue attente apparemment.

Je veux savoir ce qui est ici la meilleure solution (probablement QueueAsyncCall) et comment je peux être sûr que mon message (appel) sera traité dans des délais acceptables?

Answer 1

Vous ne pouvez pas être sûr à 100%, tout comme vous ne pouvez en aucun système non temps réel. Si les blocages mainthread, il ne vérifie pas pour les messages ou d'autres événements dans la boucle principale. Ceci est normal.

La seule chose que vous pouvez faire est d'éviter de faire des choses dans le mainthread qui peut prendre beaucoup de temps. Il est le truc du métier de juger exactement ce qui est nécessaire et ce qui est pas. Certaines personnes orientées en temps réel déplacer tous les accès de système de fichiers à des fils, et de garder l'interface graphique strictement pour l'interface utilisateur, juste parce que si un utilisateur configure un chemin sur un partage réseau pour ce ou l'autre, un problème avec la part peut facilement causer une attente trop longue attente, des minutes même.

Si je regarde application.queueasynccall, je ne vois pas de traitement de threadsafe (pas de verrouillage ou de files d'attente verrouillées), de sorte que l'on est sorti.

Je sais que PostMessage est émulé par Lazare dans une certaine mesure non Windows et j'ai vérifié la mise en œuvre et elle a serrure, je suppose qu'il est sûr multithreading.