プロパティがtrueになるまで待つ方法

何かしらのライブラリの停止処理後、確実に停止するまで待つ必要があります。
単純に実装するなら

C#
1lib.stop();
2while(lib.isActive()){}

という感じになると思うのですが、シンプルではありますがスマートじゃないかな...と思っています。
パフォーマンス的にもあまりよろしくないかな？と思っています。
パフォーマンスを気にするなら中でDelayなりすればいいとは思いますが...

そこで、C#ではこういう書き方、待ち方があるよ
ふつうはC#ならこうやって書く
いや、待つならそう書くしかない
等、皆様の知識、意見をお借りしたいと思っております。
よろしくお願いいたします。

なぜ待つ必要があるのかという点については
質問文に書いてある関数名は適当な名前にしてありますが、
stop()を呼び出してもライブラリがすぐに停止するわけでもなく、
また終了していなくとも関数はすぐに返ってきてしまいます。
停止処理後、ライブラリの終了処理を行うのですが、
完全に停止してない状態でライブラリの終了処理を呼び出すと、
終了処理内ではまってしまうという問題があります。

いや、そこはライブラリのほうで何とかしろや...
という思いはあるのですが、そういう問題があるため、isActive()がfalseになるのを待つ必要があります。

追記
プロジェクトの種類：WPF
フレームワークのバージョン：.NET Framework 4.5.2

退会済みユーザー

2021/01/25 00:49

・プロジェクトの種類(コンソールアプリ、WindowsForms、WPF とか）・フレームワークのバージョン（.NET Core X.X、NET Framework X.XXとか）を記載してください

Zuishin

2021/01/25 00:54

終了が isActive でしかわからないなら繰り返しそれを呼ぶ以外にないでしょう。GUI ならその間ユーザーの入力を受け付けなければいけませんが、CUI なら必要ありません。ただし他のアプリケーションや OS の動作を阻害するので、ライブラリ停止後すぐに何かをすることが求められるのでなければ、時間を置くのが良いと思います。Task.Delay が汎用性高いのではないでしょうか。

tuyudaku

2021/01/25 01:02

情報が少なくて申し訳ありません、追記させていただきましたので、ご確認ください。まだ、足りない情報があるようでしたら追記させていただきます。

gentaro

2021/01/25 01:04

その「何かしらのライブラリ」が提供しているAPIで停止を確実に拾えるのがisActive()しかないなら、ポーリングして監視する以外に方法がない。「何かしらのライブラリ」に手を加えられるのかどうか次第。

行動規範の内容に同意します

回答2件

ベストアンサー

提示されている情報を見る限り、待つのはisActiveで待つしかないと思うのですが、WindowsForms、WPF等のGUIアプリで、UIスレッドでこの手の無限ループをするとGUIの更新も止まってしまうので、Task.Runで別スレッドを起動して待機するようにしてください。
また、無限ループ内ではSystem.Threading.Thread.SleepやSystem.Threading.Tasks.Task.DelayでOSに時々処理を返してあげないとCPUリソースを使い果たすので危険です。

投稿2021/01/25 01:14

編集2021/01/25 01:26

退会済みユーザー

総合スコア0

Zuishin

2021/01/25 01:17

System.Threading.Thread.Sleep ですね。

退会済みユーザー

2021/01/25 01:20

指摘ありがとうございます、修正しておきます

tuyudaku

2021/01/25 01:25

やはり、そうなりますか... 回答ありがとうございます。スレッド、リソースについても十分注意してコーディングしたいと思います！助言ありがとうございました！購入しているライブラリなのですが、終了処理が返ってこないことがあるから問い合わせたら「停止処理後すぐに終了処理やってない？ちゃんとisActiveがfalseになるの待ってからやってね」って返信が来たのですが....いや、それバグでしょ... せめてドキュメントにそのこと書いておいてよ... って感じです... すみません、愚痴でした...ありがとうございました！

Zuishin

2021/01/25 01:29

そういうのはバグとは呼びません。OS でもファイル削除後すぐにファイルが削除されるとは限らないので時々そのようなコードは必要になります。

退会済みユーザー

2021/01/25 01:30

不完全なライブラリの場合、処理を補完するラッパークラス的なものを作成した方がよいでしょうね。そこに待機用のメソッドを用意すればいいと思います。

tuyudaku

2021/01/25 01:37

ライブラリ開発はしたことないので、事情などはあまりわかっていませんがそういうものなんでしょうか... 確かに、すぐにファイルが削除されるとは限らないというのはわかるのですが、終了処理の関数には成功失敗を返すboolの戻り値があるので、そこでfalse返すなり例外投げるなりしてくれればいいのに...ライブラリの関数内ではまって動かなくなるのはナンセンスでは... って使用者側の私からしたら安直にそう思ってしまいました。

退会済みユーザー

2021/01/25 01:44 編集

まあそこは設計者の意図が判らないと何ともいえないですね…完全に利用者のニーズを満たしてるライブラリじゃない事はゴロゴロあるので、そこをうまく補間するのも開発者の腕の見せ所です。設計者と話し合って、より良いライブラリに修正出来るのであればそれが一番理想ではあるのですが。

dodox86

2021/01/25 01:48

> ライブラリ開発はしたことないので、事情などはあまりわかっていませんが > そういうものなんでしょうか... 周辺機器とやり取りするようなライブラリですと、I/Oの時間、周辺機器側で時間がかかるケースがあるので、終了処理APIでは「終了要求」だけを出して、実際に終了したかどうかはisActiveのような「問い合わせ」APIを用意するようなことはあります。そうでないと、終了処理APIでブロックすることになります。ファイルもHDDやSSDのようなストレージに保存するものなので、広い意味で周辺機器、外部機器です。処理時間が長いものであれば、それ単体で外部機器ととらえることもできます。

tuyudaku

2021/01/25 01:53

確かに、私が言っているのはあくまで理想でしかないし、こうあるべきを信じてコーディングしていくのは開発者としてまだまだですね... 開発者としてレベルアップできるように頑張ります。勉強になりました！ありがとうございます！

tuyudaku

2021/01/25 01:57

>周辺機器とやり取りするようなライブラリですとまさにそうですね、周辺機器とやり取りをするようなライブラリです。「そういうものだ」という言い方もあれですが、やはり、そういうものなんですね。 isActiveのようなプロパティがあるものはもう少し注意しながら意味を考えて、仕様を確認してコーディングしていきたいと思います！ありがとうございます！