4

メインスレッドのコンテキストでコードを実行する必要があります。Lazarus + FPC を使用しています。DLL (Linux の場合は共有ライブラリ) 内のスレッドからイベントを受け取り、コールバック関数が呼び出されます。この関数はどのクラスのメンバーでもなく、「cdecl」ディレクティブが付加されたスタンドアロンの従来の関数であることに注意してください。

このようなメッセージを受信するたびに、対応するプロパティ イベント ハンドラーをトリガーする必要があります。これらのイベントは、メイン スレッドのコンテキストで渡す必要があります。私は2つのそのような解決策を知っています:

  1. 投稿メッセージ
  2. Application.QueueAsyncCall

最初のものは問題ありませんが、ウィンドウ ハンドルが必要です。これはライブラリ コードであるため、使用できるハンドルはありません。AllocateHWND はクロス プラットフォームではないため、オプションではありません。ダミーフォームを作成できることは知っていますが、これは非常に悪い解決策です

2番目は問題なく動作しますが、たとえばアプリケーション内でマウスを移動するまで呼び出しが処理されないという問題があります。たぶん、私は何か間違ったことをしているのかもしれません。メッセージ処理が開始されたときにのみ通話が処理されているようです。しかし、これは明らかに長い待ち時間になる可能性があります。

したがって、ここでの最善の解決策 (おそらく QueueAsyncCall) と、メッセージ (呼び出し) が許容時間内に処理されることを確認する方法を知りたいですか?

4

1 に答える 1

1

非リアルタイム システムと同じように、100% 確信することはできません。メインスレッドがハングした場合、メイン ループ内のメッセージやその他のイベントはチェックされません。これは正常です。

あなたができる唯一のことは、メインスレッドで長い時間がかかる可能性があることを避けることです。必要なものとそうでないものを正確に判断するのが商売のコツです。一部のリアルタイム指向の人々は、すべてのファイルシステム アクセスをスレッドに移動し、GUI を厳密に UI 用に保持します。これは、ユーザーがネットワーク共有のパスをこれまたは別のネットワーク共有に構成した場合、共有の問題により簡単に長いタイムアウト待機が発生する可能性があるためです。数分でも。

application.queueasynccall を見ると、スレッドセーフな処理 (ロックまたはロックされたキューがない) が表示されないため、アウトになっています。

Windows 以外で postmessage が Lazarus によってある程度エミュレートされていることは知っています。実装を確認したところ、ロックがかかっているので、マルチスレッドで安全だと思います。

于 2010-08-27T09:50:12.747 に答える