C#, C♯, C＃相談室 Part94

2019/03/20(水) 18:57:36.47

!extend:checked:vvvvv:1000:512
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part93
http://mevius.5ch.net/test/read.cgi/tech/1492818720/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2021/10/07(木) 04:29:01.91

HOMOHOMOHOMOHOMOHOMOHOMOHOMOHOMOHOMOHOMOHOMOHOMO

2021/10/08(金) 20:11:01.95

>>771-773
これすごい機能だな
.NET 6から新規プロジェクト作成するとデフォルトで有効になると書いてある
引き継いだから知らなかった

2021/10/17(日) 11:37:08.06

>>780 >>781
レスありがとうございます　返信遅くなりました
参考にいろいろやりましたが結局FTPで切断して中止させる方が簡単で
送信データ量などの進捗が拾えて残り時間の計算も簡単なので
NASとFTPでやりとりすることに落ち着きました

2021/10/18(月) 18:50:18.68

MSの.NETチームってアジア人少ないのか？
表に出てくるメンツ見てると黒人とかラテンアメリカンはちょいちょいいるのにアジア人がほぼいないんだが、
アメリカのIT企業って総じて黒人よりアジア人の方が従業員比率高いはずなのにおかしいだろ
ポリコレソードで一刀両断して良いか？

2021/10/18(月) 21:33:52.17

何のために？

2021/10/18(月) 22:56:12.18

>>785
キモッ！

2021/10/19(火) 09:12:00.45

ブリザードの闇を知ってからはアメリカのIT業界も色々とやべぇんだなとは思った
ああいう闇があるからこそ日本人からは到底理解できないようなポリコレが流行るのも致し方ないと思えるようになったわ

2021/10/19(火) 10:22:17.02

Streamで非同期のreadを行っています。Stream.BeginRead(～);
このBeginReadをキャンセルするにはどうすれば良いのでしょうか。

通常の読み込みだと、BeginReadで指定したコールバック先でStream.EndRead(～);を実行するのですが、1バイトも受信していない場合、EndReadを実行すると待ち状態になってしまいます。

2021/10/19(火) 10:44:59.71

StreamをDisposeすればEndReadで例外が出る

2021/10/19(火) 10:55:17.24

>>790
BeginRead をキャンセルしたいのは、同じストリームに出力を行いたいためです。
なので、Streamは破棄できません。

2021/10/19(火) 14:36:25.49

>>789
BeginRead 見たら ReadAsync の使用を検討しろって書いてあるからそうしたら？

2021/10/19(火) 15:15:21.66

Readがデッドロックするような状態なら常識的にはWriteが成功するとは
考えにくい気がするんだけど違うのかなw

2021/10/19(火) 15:37:59.83

デッドロックは言葉の使いどころが違うと思う

ReadAsyncでCancellationToken渡したとしても
CancellationTokenSource.Cancelでキャンセルできるかどうかは具象クラスの実装次第なのに注意
.NET Core系は多分問題ないと思うけど.NET Framework系はあんまりサポートしてない印象

2021/10/19(火) 15:58:37.60

デッドロックがどこで出たかわかりませんが、やりたいのは名前付きパイプでのプロセス間の相互送受信です。

2021/10/19(火) 18:22:02.29

>>789
適当なこと書くけど、コールバック先の中でEndReadするのだと、データの読み取りが
完了しない限り実行されないのでダメなのではないかな？
やるならばBeginReadの返却値であるIAsyncResultの内容を保存しておいて、Read
処理をやめたくなったら、保存しておいたIAsyncResultの値をEndReadに指定して
呼び出すんじゃないのかな？

2021/10/19(火) 18:27:10.49

>>794
確かに「自分で自分の処理が完了するのを待つ」
状態に陥ることを指す場合が多いけど、
単純に何かの処理が終わらないことや終わらないことも
デッドロックと言うと思うけどね。

>>795
それならReadをキャンセルする必要なんか最初からないのでは？

2021/10/19(火) 18:29:59.71

>>797
デッドロックについて言ってること全部間違ってるように見える

2021/10/19(火) 18:32:13.92

>>797
言いません

2021/10/19(火) 18:42:34.22

絶対言わない

2021/10/19(火) 18:45:34.17

>>798-800
いや言うからw
言うまでもないけどdeadlockは座礁のこと。
つまり身動きが取れなくなることなんだよ。
それは自分で自分を待つケースに限らない。

2021/10/19(火) 18:47:21.34

勘違いも甚だしい

2021/10/19(火) 19:18:16.00

>>801
やはり勘違いしてるな

2021/10/19(火) 19:26:02.78

デッドロックとは
対策に徹夜で３日以上かかるバグの事を指す

2021/10/19(火) 19:32:00.07

>>801
英語の元の意味と業界用語が違うなんていくらでもあるぞ
NIC の promiscuous (mode) とか調べてみw

2021/10/19(火) 21:14:28.92

そもそも名前付きパイプって同一のストリームを読み書き両用でつかえるのか？

2021/10/19(火) 22:15:54.02

組み込みの資格の問題集では、
デッドロックは、資源のたすき掛け

タスクA が、資源X, Y の順にロックして、
タスクB が、資源Y, X の順にロックする

ここで、どのタイミングでデッドロックが起きるか、という問題

2021/10/20(水) 02:56:42.16

rubyガイ、お前には聞いてない
しゃしゃるな

2021/10/20(水) 09:16:14.30

>>804
発見に3日以上
対策は3秒
だろ

2021/10/20(水) 09:18:08.43

>>806
OK

**789** (ﾜｯﾁｮｲ ef4b-0ECy) · 2021/10/20(水) 09:47:41.27

最初から説明すると、やりたいのは.NET5のWorkerServiceで作成したWindowsサービスの状態をタスクトレイに表示することです。
Windowsサービスから直接タスクトレイに表示する事が出来ないということで、タスクトレイ表示用のフォームアプリを作成。
両者間でプロセス間通信を行い、フォームアプリからWorkerServiceへの問い合わせという形では問題なく通信できました。
※フォームアプリ：送信専用/WorkerService：受信専用

ただ、WorkerServiceの状態が変わるのは希なことなので、フォームアプリから頻繁に問い合わせるのは無駄が多いので、
フォームアプリからWorkerServiceへの接続以外はWorkerService側からのPush通信を行うように修正しました。
フォームアプリ：受信待機、WorkerService：送信。WorkerService：受信待機、フォームアプリ：送信のテストは正常に終わりました。
送信はいつ発生するかわからないため、双方を受信待機にしたところ、その状態では送信が出来ません。
受信待機状態で無ければ送信出来るのは確認しているので、受信待機を解除出来れば送信出来ると考え、その方法を探している途中です。

>>806
上に書いているとおり、受信待機状態で無ければ送信できます。もちろん、受信待機状態で相手から送信されれば受信できます。
実際にテストし、確認しています。

**789** (ﾜｯﾁｮｲ ef4b-0ECy) · 2021/10/20(水) 10:34:02.67

>>796
コールバック先ではなく、送信用関数の頭でキャンセルするようにしています。
BeginReadの返り値を保存。キャンセルしたい場所でEndReadの引数に渡すようにしているのですが、EndReadを呼び出すとそのままだんまりです。
なので、なにか手順でもあるのかと思い、検索をかけたのですが解決法がわからないため、ここで質問しました。

2021/10/20(水) 10:39:51.36

>Windowsサービスから直接タスクトレイに表示する事が出来ない

サービスの登録で「デスクトップとの対話を許可」してあれば表示出来ますよ？

2021/10/20(水) 10:42:48.21

送信がちゃんと動いてるならそこ変える必要なんてないし
送信と別に受信用の接続つくれば解決するんじゃ

**789** (ﾜｯﾁｮｲ ef4b-0ECy) · 2021/10/20(水) 10:51:47.47

>>813
.NET 5 ではサポートされないと、どこかで読んだ覚えが・・・
参考になるWebPage等あれば教えてください。
直接やった方が単純なので・・・

2021/10/20(水) 11:37:20.61

Windows 管理ツール
→ サービス
サービス名で右クリックしてプロパティ → ダイアログ → ログオン
「デスクトップとの対話をサービスに許可」にチェック

HKLM\\SYSTEM\\CurrentControlSet\\Control\\Windows\\NoInteractiveServices
0にする必要があるかも

**789** (ﾜｯﾁｮｲ ef4b-0ECy) · 2021/10/20(水) 14:16:23.47

>>816
教えていただきたいのは設定の方法ではなく、.NET 5のServiceWorkerでタスクトレイにアイコンを表示する方法です・・・

2021/10/20(水) 15:27:59.69

さすがにサービス作るのは面倒だから同一プロセス内で試しただけだけど
BeginRead中に普通にWriteできたよ
NamedPipeXxxStreamをnewする時にPipeOptions.Asynchronous指定してる？

2021/10/20(水) 15:55:53.51

https://atmarkit.itmedia.co.jp/ait/articles/1704/11/news015.html

2021/10/20(水) 16:10:12.00

>>818
していませんでした。
サーバ、クライアント双方にオプションを指定し、Stream.Read中にStream.Writeが可能なことを確認しました。
ありがとうございます。

2021/10/20(水) 17:19:49.71

前提をすっ飛ばすと突拍子もない解決手段を思いつきそれを実現しようとしてしまい四苦八苦する典型例みたいですね

2021/10/20(水) 18:07:28.07

レジ袋有料化みたいな話だね

ただ、批判する意図はないけど、位置の概念がないストリームなら普通「全二重」であるはずだ、
ってのはちょっと考えれば気づけたはずじゃなかなとは思う

2021/10/20(水) 18:43:57.39

出来ることを出来ないと思い込んじゃったとこから始まってるんだな。
サービスからのタスクトレイアイコン然り、Streamのリードライトも然り。

2021/10/21(木) 11:54:41.56

>位置の概念がないストリームなら普通「全二重」であるはずだ
お前の勝手な思い込みだとしか思えん

2021/10/21(木) 12:25:32.61

イキり馬鹿には「普通は」って文字が読めないんだな

2021/10/21(木) 13:30:46.89

>>822
その方法で判断してるなら既にいくつかバグ孕んでそう

2021/10/21(木) 14:41:10.46

r/wを排他的にせざるをえない必然性や制約が存在しない限りわざわざ排他的にする合理性はないというだけの話。
馬鹿じゃないの。

というか、例えば2.0までのUSBは物理層が「半二重」だが、上位の層ではそんなことを
意識する必要はないようにしてある。

そんな制約を意識する必要があったらやってられないからだ。
必要もないのにそんな制約を課す馬鹿がどこにいる

2021/10/21(木) 16:22:37.02

双方向に通信できるか、一方向にしか通信できないことと、全二重半二重は別の概念じゃない？
双方向通信になって初めて半二重なのかと考える必要があるし、そもそもIPCをOSのAPIで使ってるときにそんなにシビアに考えることかな？という気がする

2021/10/21(木) 16:25:27.19

双方向のプロセス間通信なら、パイプじゃなくてIPC使ったほうが楽じゃね？

2021/10/21(木) 22:48:54.75

>>825
お前の言う「普通」はお前の思い込みだって指摘だが、普通が読めないとかどっから出てくる話だ

そもそも位置の概念と双方向か片方向かは関係ないし
双方向のストリームは全2重であるべきだって意見なら理解しないではないが
お前の希望が普通に実装されてるとは限らんのだよ

2021/10/22(金) 03:27:01.26

白鳥は普通白い、というのは全称命題（黒い白鳥はいない）ではない。
イキり馬鹿って本当に馬鹿で笑えるねw

ファイルのように位置の概念があるストリームでは排他的にr/wされたら困るだろうw
馬鹿じゃなかろうかマジで

2021/10/22(金) 03:28:52.19

× 排他的に
〇非排他的に

2021/10/22(金) 03:58:09.76

最近ヤフコメの規制が話題になってるけど、
webくんだりで他人に居丈高な態度を取る奴の動機の源泉（うだつ上がらない）
なんて見え透いてるよねw

別にうだつ上がらないのは悪くないが（俺もそうだし）
いい歳こいてそういう自分の動機を自覚できないのも、他人から自分がどう見えているかを
意識できないのもかなり痛々しいよねえw

2021/10/22(金) 07:26:26.05

括弧の中はコーラスかな

2021/10/22(金) 08:40:47.54

うだつってどこで売ってるの？

2021/10/22(金) 08:47:26.63

>>831
普通のファイルのシークしながらの読み書きなら困る、はわかるんだけど、
それを一般化して、位置の概念のあるストリームで「普通」成り立つべき性質なのかよくわからない。
後学のために、いい例を教えてくれないか？

2021/10/22(金) 11:28:17.10

そもそもファイルストリームって（単一ファイルでは）双方向通信に使えるものじゃないから、
全二重という思い込みがよく分からないし
ﾜｯﾁｮｲ的にデッドロックの意味勘違いしてた人っぽいし
全般的に用語の使い方がいい加減な人なんだろうなと思った

2021/10/22(金) 11:54:11.71

ファイルストリームって、追記モードで複数オープンされたファイル扱えないのか？

2021/10/22(金) 12:08:46.46

双方向のストリームなら、非排他的にアクセスされると困るという意見ならまあ理解はできる

排他的とか、自分以外のアクセスの話で、自分が全２重でアクセスできるかどうかとは無関係だがな

2021/10/22(金) 12:47:13.67

>>837
なるほど
全２重/半２重から排他/非排他の話になってるのは
話をずらそうとしてるんじゃなくて自分の中でもちゃんと区別できてないのか

2021/10/24(日) 03:48:37.41

>>837
俺が用語を正確に使ってないのでなく君に読解力がないだけじゃないのかな。

俺はファイルストリームは「半二重」だと言ってるんだよ。わざわざ括弧を付けて。
括弧を付けているのは全二重/半二重という用語は普通はストリームを対象にした
用語ではないからだ。

2021/10/24(日) 03:54:05.25

というか、「必要のない制約をわざわざ課す馬鹿っているんですか？」
っていうのが俺の主張の本質なんだけど、その辺も含めて文脈読めないにも程があるね。

2021/10/24(日) 06:21:08.23

ああ、ほんとに双方向か片方向かと全／半２重の区別がついてないのね

2021/10/24(日) 10:19:03.31

全二重と半二重は鉄道で例えれば単線と複線の違いだよ。
RS485通信は半二重通信になるけどな。

2021/10/24(日) 12:15:38.06

>>843
またそれか。
片方向の文脈であれば全二重/半二重の区別は意味を持たない。
区別がついてないのは君じゃないの。マジで大丈夫か

2021/10/24(日) 12:24:26.91

だいたい双方向とか片方向とかいう話がどっから出てくるのw
意味がわからないよ

だから、必要もないのにr/wを排他的にする制約を課す馬鹿っているの？って話をしてるんだけど

2021/10/24(日) 12:31:01.70

次の展開予想すると、>>843みたいな人はたぶんそれでも片方向/双方向の違いに固執して
「片方向っていうのは片方だけが能動的にr/wすることをいうんだ」みたいな話になるんだろうねw

だから、だから何だよw
この文脈でそれ重要ですか？

2021/10/24(日) 15:32:33.07

ああ、排他的ってのは自分自身からのリードとライトについて言っているのか
つまりお前の中では、全2重＝非排他的　半２重＝排他的　ってことなのね
で、片方向っていうのは片方だけが能動的にr/wすること　だと

まあこれからも独自路線を行ってくれ。できればひっそりと

2021/10/24(日) 16:20:34.86

ファイルストリームに半二重ないやろ？
途中で方向変わるのか？
全二重もないし。

2021/10/24(日) 16:40:45.22

誰かこいつらの脳幹をdisconnectしてくれや

2021/10/24(日) 17:30:30.88

NO CARRIER

2021/10/24(日) 20:36:34.43

>>847
既に定義された用語と違う独自用語使うならスレ外でやれ
デッドロックがどういう状態かの理解はできたか？

2021/10/25(月) 08:10:52.85

海外の機関車のハンドルとかについている装置
運転手が突発性の病気で倒れたりして手を離すと緊急停止する

2021/10/25(月) 09:43:28.98

つまんね・・・

2021/10/25(月) 15:32:53.27

鎌池和馬の言の葉、我が身に降臨す。

2021/10/25(月) 19:07:57.24

>>853
それは Dead man's switch

2021/10/25(月) 19:38:31.87

>>852
いい機会だから言っておくか。
それは違う。

言葉というのは置かれた文脈によって意味が変わる、
という中学生でも知っている事実を君が知らないだけじゃないの？

だいたい文脈無視して意味不明な用語法の問題にすり替えて、
それを指摘されてもまだ「おかしいのはお前だ」と言い張る神経が俺には理解できない。

2021/10/25(月) 19:42:31.57

あと>>833ねw

2021/10/25(月) 20:07:49.31

どうでもいいけど技術的なやり取りをするのに言葉の意味を明確に定義せずにするのは困難しか産まないと思うけどな。

独自用語でもちゃんと定義したらよろしい。

定義なしに文脈によって意味が変わるなんて言ってるのは技術者失格。

2021/10/25(月) 22:36:46.73

えっちょっと待って
IT用語としての「デッドロック」なんて基本情報レベルな単語だしこの板に書き込むような人なら常識だと思ってたんだけど
>>801なんかはてっきりギャグとして書いてるか、さもなくば
デッドロックって言葉の意味を知らない人を馬鹿にするためにわざと書いてると思ってたんだが
ひょっとして本当に知らなかったの??

でもって無知を恥じるでもなく「読解力」とか言い出して責任転嫁してるの？
「ボクチャンわるくないもん、読み手が馬鹿なのが悪いんだもん」って言ったところで
馬鹿をさらしてる人が言い出したところで説得力ないと思うよ
そのうえさらに自分の語用・論理展開が支離滅裂なのを棚に上げて「文脈」とか言い出して正当化してもなあ
>それを指摘されてもまだ「おかしいのはお前だ」と言い張る神経が俺には理解できない。
その言葉を反芻すべきなのは>>857だと思うよ

2021/10/25(月) 22:56:47.64

文脈無視して意味不明な用語法ってか
さすが自分の常識は絶対だって自信がある人はちがうな

で、技術論を人格攻撃で逃げようってか
相手してられん

2021/10/25(月) 23:12:43.16

デッドロックマンﾃｨｳﾝﾃｨｳﾝｗｗｗ

2021/10/26(火) 01:05:29.94

お前らそろそろ落ち着きませんか？
c#10の話でもしようぜ(錯乱)

2021/10/26(火) 01:13:31.28

特定の会社なりグループなりの小さなコミュニティ内で本来の定義とは異なる意味で用語が使われることはある
そのコミュニティ内で齟齬なく意思疎通取れてるならまぁ問題ない
ただその輪から出たら本来の意味でのみ使用すべきだし誤解を招きそうなら補足を入れるなりすればいい

定義にシビアなことが求められる技術者がこういう場で文脈によって変わるとか言っちゃうのはどうかと思う
こういう場というのが便所の落書きじゃん、というなら否定はできんがｗ

2021/10/26(火) 01:23:54.20

みんなわかっているくせにいつまでも指摘しないのな。

デッドロックは暗礁でも座礁でもない。壊れた錠前のことだ。

https://www.nhk.or.jp/bunken/summary/kotoba/gimon/170.html

IT 用語では、並列処理時に異なるプロセスが、互いが専有するリソースの解放を求めて睨み合い、うごけなくなってしまうリソース競合のことだ。それ以外の意味はない。

一般用語に行き詰まりという意味があったとして、IT 用語としてリソース競合という意味のズバリの状況定義があるのだから、IT に正しい理解がある人間なら、行き詰まりという一般的な意味でこの語を IT 関連の説明に使うことは絶対に避ける。他人に誤解させるし、伝わらないし、紛らわしいのが目に見えているから。

色々な意味で、非常に恥ずかしい部類の誤用。強弁もたいがいにしておくべき。

2021/10/26(火) 01:34:11.65

✕専有→○占有

2021/10/26(火) 02:21:50.02

誰かこいつらをガイジ小学校に叩き込んで来てくれや

2021/10/26(火) 07:39:00.23

>>865
壊れた錠前とかそういう比喩でなく、
膠着状態を指す英単語だよ
a situation in which a disagreement cannot be settled.

2021/10/26(火) 09:42:42.07

そもそもdead rockなんて勘違いしてる奴いないじゃん
座礁って言葉使ってる奴はいるけど身動き取れなくなると説明付き
リソース競合ってまた狭い意味だし座礁と同じで狭い意味でデッドロックを使ってる
デッドロック（IT限定）でもプロセス競合のほうがまだまし
しかも競合それ自体には行き詰まりの意味はない
あくまでも競合による行き詰まりがデッドロック

2021/10/26(火) 11:09:30.80

座礁がdead rockからきた勘違い
deadlockは身動き取れなくなるという意味はない

語源はdead+lockだから「壊れた錠前」であってるけど
今はその意味で使われることはない

2021/10/26(火) 11:53:16.92

>>870
座礁もdeadlockで間違いないし、rockとの勘違いでもない
ただ英単語としての意味とIT用語としての意味を混同していたことが問題なだけ

2021/10/26(火) 12:21:43.14

まだやってんのかい。
お前ら、仲いいな。

2021/10/26(火) 12:43:29.66

たんなるウェイトとデッドロックの区別がついてないバカがうだうだ言ってるだけ

2021/10/26(火) 12:57:34.74

>>865
壊れた錠前では無いよ。
行き詰まりそのもの。
リソースのlock自体、錠前のことではない。
名詞としてのlockは、カギで開け閉めするものに限られるので、リソースなどを指してない。輪留めとか、にっちもさっちもいかない状態とかそういうのを指す。

動詞としては、固定するだよ。
リソースを取得するのにカギが必要なら錠前だろうけど、カギは要らない。

2021/10/26(火) 13:49:40.40

>>871
Pope Francis urges end to migrant boat deadlock
https://www.bbc.co.uk/news/world-europe-46777844

↑この船は座礁してるのかな？

2021/10/26(火) 14:28:12.06

多義語を知らない>>875
辞書引くだけで良いのに引けないんだね

2021/10/26(火) 18:40:21.38

>>876
座礁って書いてある辞書教えて
そしたら納得するよ

2021/10/26(火) 19:44:50.29

>>877
納得はいらんけど、deadlockの自動詞、他動詞の意味調べてみ

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 6247-SMpf) · 2021/10/26(火) 20:18:17.44

>>878
低頓する、低頓させる、「交渉は賃金問題で行き詰まった」、旺文社シニア英和辞典
行き詰まる、行き詰まらせる、低頓する、低頓させる、研究社リーダーズ英和辞典

2021/10/26(火) 20:48:48.62

さすがに「言葉の意味は文脈に依存する」ってことを知らない人がこれだけ多いと日本の将来心配になるねw

この業界でデッドロックと言えば普通は非同期処理の文脈におけるデッドロックのことを指す、
これは最初から言っているように間違いない。

ただ必ずそうとは限らないと言ってるだけ。
イキってる皆さんがどう思おうが自由だけど、メソッドが制御を返さない状態のことをその原因を問わずに
「デッドロック」と呼ぶ用法は普通に使われてる。

2021/10/26(火) 20:52:50.16

そもそもデッドロックの意味とか、片方向と双方向の違いがどうのとか、そんなのどーでもいいわw
誰がそんな話してるんだよw

俺は時々ニュース系の板とかでネトウヨ馬鹿にして楽しませてもらってるけど、
この追いつめられると別の矮小な問題にすり替えて誤魔化して逃げるやり方って
連中そのものだねw