問題タブ [cancellation]

ユーザーが WPF TextBox に入力できるようにしたい状況があります。キーストロークごとに OnPropertyChanged を呼び出し、バインディング ソースにプッシュします (SourceUpdatedTrigger=PropertyChanged を使用)。 (たとえば... 1 秒) これは、ユーザーが入力を停止するのを待ってから、スペルができないと伝えるスペル チェック システムのようなものだと考えてください。

私の問題は次のとおりです。

実際にキャンセルするまでは正常に動作しますが、キャンセル トークン ソースは永続的に「キャンセル要求」状態になり、CTS を再インスタンス化する必要があります...これは...根本的に間違っているようです...もっと良い方法はありますか?" CTS をリセットしますが、キャンセルする必要があることを既存のトークンに通知しますか?

私たちのアプリケーションは、TPL を使用して (潜在的に) 長時間実行される作業単位をシリアル化します。作業 (タスク) の作成はユーザー主導であり、いつでもキャンセルできます。レスポンシブなユーザー インターフェイスを実現するために、現在の作業が不要になった場合は、これまで行っていたことを破棄して、すぐに別のタスクを開始したいと考えています。

タスクは次のようにキューに入れられます。

このDoWorkメソッドには実行時間の長い呼び出しが含まれているためtoken.IsCancellationRequested、キャンセルが検出された場合はステータスを常にチェックして救済するほど単純ではありません。長時間実行される作業は、タスクがキャンセルされた場合でも、終了するまでタスクの継続をブロックします。

この問題を回避するための 2 つのサンプル メソッドを考え出しましたが、どちらも適切であるとは確信していません。簡単なコンソール アプリケーションを作成して、それらがどのように機能するかを示しました。

注意すべき重要な点は、元のタスクが完了する前に継続が開始されることです。

試行 #1: 内部タスク

これは機能しますが、「innerT」タスクは私にとって非常に扱いにくいと感じています。また、この方法で作業をキューに入れるコードのすべての部分をリファクタリングしなければならないという欠点もあります。これは、実行時間の長いすべての呼び出しを新しいタスクにまとめる必要があるためです。

試行 #2: TaskCompletionSource の調整

繰り返しますが、これは機能しますが、2 つの問題があります。

a) TaskCompletionSource の結果を決して使用せず、作業が終了したら null を設定するだけで、TaskCompletionSource を悪用しているように感じます。

b) 継続を適切に接続するために、作成されたタスクではなく、前の作業単位の一意の TaskCompletionSource のハンドルを保持する必要があります。これは技術的には可能ですが、やはりぎこちなく奇妙に感じます。

ここからどこへ行く？

繰り返しますが、私の質問は次のとおりです。これらの方法のいずれかがこの問題に取り組むための「正しい」方法ですか、それとも、長時間実行されているタスクを途中で中止してすぐに継続を開始できる、より正確でエレガントなソリューションがありますか? 私の好みは影響の少ないソリューションですが、それが正しいことであれば、大規模なリファクタリングを喜んで引き受けます。

あるいは、TPL はジョブに適したツールでさえあるのでしょうか、それともより優れたタスク キューイング メカニズムが欠けているのでしょうか。私のターゲット フレームワークは .NET 4.0 です。

SQL サーバーに次のようなストアド プロシージャがあります。

アプリケーションから呼び出され、実行に数秒かかります。実行中にユーザーがキャンセルすると、レコード テーブルに StartTimestamp が表示されますが、エラーも EndTimestamp もありません。ユーザーがこのストアド プロシージャを開始したことを常に知りたいのですが、成功、エラー、またはキャンセルのいずれかによって終了したときも常に記録したいと考えています。

SQL Server でそれを行う方法はありますか?

ありがとう

誰かがスターバックスからPCにログインし（たとえば）、誤って「remember me」オプションをチェックして、そのPCに永続的なCookieを設定した場合、Cookie名を変更せずにサーバーからそのCookieを拒否する方法はありますか？ web.configで？

キューへの同時アクセスの制御を抽象化することを目的としたクラスを作成しました。

このクラスは、単一のスレッドでインスタンス化され、複数のスレッドによって書き込まれ、後続の単一のスレッドから読み取られるように設計されています。

クラス内で生成された単一の長時間実行タスクがあり、アイテムが正常にデキューされた場合にブロッキング ループを実行し、イベントを発生させます。

私の質問はこれです:私の実装は、長時間実行されているタスクのキャンセルと、その後のCancellationTokenSourceオブジェクトの正しい使用方法のクリーンアップ/リセットですか?

理想的には、キューに追加する可用性を維持しながら、アクティブなオブジェクトを停止および再起動できるようにしたいと考えています。

Peter Bromberg の記事をベースとして使用しました: Producer/Consumer Queue and BlockingCollection in C# 4.0

以下のコード:

更新 これが私が最後に行ったことです。完璧ではありませんが、これまでのところ仕事をしています。

出力は次のとおりです。

http://msdn.microsoft.com/en-us/library/dd321703.aspxによると、AggregateException が発生すると予想していましたが、ここでは throwOnFirstException パラメーターは意味をなさないようです。私のコードの何が問題なのですか。

シグナルハンドラー内から、シグナルが処理されたときにそのように行われているシステムコールを条件付きで中断する方法を探しています。これを具体的にするために、 への呼び出しreadが処理中で、SIGRT0受信されたとします。このシグナルハンドラはSA_RESTARTシステムコールを無条件に割り込ませたくないので使っていますが、条件によってはシグナルハンドラが戻ってきたらすぐreadに返してもらいたいです。EINTR

これを行う 1 つの方法は、 の別のシグナル ハンドラーを設定し、 のハンドラーのシグナル マスクをSIGRT1入れて、ハンドラーから除外することです。次に、canのハンドラーがあり、最初の中断しないシグナルハンドラーが戻ると、2番目のハンドラーが起動して中断されます。SIGRT1SIGRT0SA_RESTARTSIGRT1SIGRT0raise SIGRT1read

このソリューションの問題点は、他のプロセスが を送信SIGRT1して、不要なEINTR発生を引き起こす可能性があることです。

私が探している結果を達成する方法はありますか?

私の質問は、障害アドレスについて尋ねた他の質問とは多少異なります。恐ろしいハックを実装して、シグナルハンドラーから、保存された命令ポインターのコードを調べて、ホストアーキテクチャの可能なsyscallエントリ命令と比較することにより、シグナルがsyscallまたは通常のユーザーコードを中断したかどうかを判断しようとしています。で実行しています。これは、私の古い質問で説明した競合状態やリソースリークの影響を受けない正しいPOSIXスレッドキャンセルの実装の一部です。

POSIXキャンセルポイントはどのように動作するはずですか？

このアプローチが信頼できないか、そうでなければ間違っている場合は、理由も聞きたいと思います。

たとえば、アプリケーションがキャンセル ポイントでブロックされ、readシグナルが受信され、シグナル ハンドラが呼び出されたとします。Glibc/NPTL は、syscall の実行中に非同期キャンセルを有効にすることでキャンセル ポイントを実装しているため、私が知る限り、非同期キャンセルはシグナル ハンドラーの実行中に有効なままになります。もちろん、これはひどく間違っています。非同期キャンセルセーフではないが、シグナルハンドラーから安全に呼び出す必要がある関数がたくさんあるからです。

これにより、2 つの質問が残ります。

• 私は間違っていますか、それとも glibc/NPTL の動作は本当に危険なほど壊れているのでしょうか? もしそうなら、そのような危険な行動は準拠していますか?
• POSIX によると、プロセスがキャンセル ポイントである関数を実行しているときにシグナル ハンドラが呼び出された場合、どうなるでしょうか。

編集:pthread_cancel潜在的なターゲットであるスレッドは、キャンセルポイントである関数がそのスレッドのコンテキストでシグナルハンドラーから呼び出されないようにする必要があることをほぼ確信しています:

一方では、キャンセルされる可能性があり、async-cancel-unsafe 関数を使用するスレッドで呼び出すことができるシグナル ハンドラーは、キャンセル ポイントである関数を呼び出す前にキャンセルを無効にする必要があります。これは、シグナルによって割り込まれたコードの観点からは、そのようなキャンセルは非同期キャンセルと同等であるためです。一方、シグナル ハンドラーは、非同期シグナル セーフではないため、シグナル ハンドラーが呼び出されたときに実行されるコードが非同期シグナル セーフ関数のみを使用しない限り、取り消しを無効にすることはできませpthread_setcancelstateん。

現在、サービスエンドポイントとして公開されている単純なワークフローがあります。サービスはワークフローインスタンスIDに関連付けられ、すべてが期待どおりに機能します（ReceiveBegin、Executeの2つのサービス呼び出しが利用可能）。

私の問題は、ユーザーがワークフローで別の受信を呼び出すことによって、ワークフローの長時間実行されている部分をキャンセルできるようにしたいということです。ご覧になりましたWorkflowApplication.Cancelが、これをWCFサービスとして実行しているため、利用できないようです。

ドキュメントはこの領域については少し軽いようで、ほとんどのHOLと例は、ワークフローをホストするコンソールアプリに焦点を当てています。