2

ブーストドキュメントは言うが

例外がキャッチされた後、run()、run_one()、poll()、または poll_one() 呼び出しは、reset() への呼び出しを介在させなくても再開できます。

私は違う経験をしています。

例外ハンドラーで、停止状態の io_service を見つけて、その後の非同期作業の追加の試みが失敗したため、次の run() 呼び出しがすぐに終了します。

これは私がやっていることと非常に似ています:

...
io_service ios;
do_receive(); // adds some async work to ios 
do try
{
    ios.run();
    break;
}
catch (std::exception const &)
{
    assert (ios.stopped()); //<----- ASSERTION DOESN'T TRIGGER. i.e ios is stopped
    ios.reset();            //<----- ...So I need to do this otherwise next call
                            //<----- to do_receive() fails to add more async work
                            //<----- causing next loop iteration's run() invocation
                            //<----- to exit immediately

    do_receive(); //same as above, adds async work to ios
}
while(1);

新しい非同期作業を追加しようとする前に io_service の reset() への呼び出しを追加すると、問題は解決したようですが、複数のスレッドが run() を呼び出している場合、これがどのようにスケーリングされるかわかりません。

いずれかのハンドラーがスローした場合、catch ブロックはそのスレッド コンテキストでリセットを呼び出し、他のすべての実行中の操作をひどく混乱させると思います。

ブーストドキュメントで何か間違っているか、何か不足していますか?

ありがとう、アンドレア。

4

1 に答える 1

2

io_service行う作業がなくなると、 は自動的に停止します。それがおそらくここで起こっていることです。それを防ぎたい場合は、io_service::workオブジェクトを作成することで実現できます。io_serviceオブジェクトが存在する限り、 は停止しません。

于 2013-09-26T16:37:02.543 に答える