C#, C♯, C#相談室 Part94
■ このスレッドは過去ログ倉庫に格納されています
!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 >>798-800 いや言うからw 言うまでもないけどdeadlockは座礁のこと。 つまり身動きが取れなくなることなんだよ。 それは自分で自分を待つケースに限らない。 デッドロックとは 対策に徹夜で3日以上かかるバグの事を指す >>801 英語の元の意味と業界用語が違うなんていくらでもあるぞ NIC の promiscuous (mode) とか調べてみw そもそも名前付きパイプって同一のストリームを読み書き両用でつかえるのか? 組み込みの資格の問題集では、 デッドロックは、資源のたすき掛け タスクA が、資源X, Y の順にロックして、 タスクB が、資源Y, X の順にロックする ここで、どのタイミングでデッドロックが起きるか、という問題 最初から説明すると、やりたいのは.NET5のWorkerServiceで作成したWindowsサービスの状態をタスクトレイに表示することです。 Windowsサービスから直接タスクトレイに表示する事が出来ないということで、タスクトレイ表示用のフォームアプリを作成。 両者間でプロセス間通信を行い、フォームアプリからWorkerServiceへの問い合わせという形では問題なく通信できました。 ※フォームアプリ:送信専用/WorkerService:受信専用 ただ、WorkerServiceの状態が変わるのは希なことなので、フォームアプリから頻繁に問い合わせるのは無駄が多いので、 フォームアプリからWorkerServiceへの接続以外はWorkerService側からのPush通信を行うように修正しました。 フォームアプリ:受信待機、WorkerService:送信。WorkerService:受信待機、フォームアプリ:送信のテストは正常に終わりました。 送信はいつ発生するかわからないため、双方を受信待機にしたところ、その状態では送信が出来ません。 受信待機状態で無ければ送信出来るのは確認しているので、受信待機を解除出来れば送信出来ると考え、その方法を探している途中です。 >>806 上に書いているとおり、受信待機状態で無ければ送信できます。もちろん、受信待機状態で相手から送信されれば受信できます。 実際にテストし、確認しています。 >>796 コールバック先ではなく、送信用関数の頭でキャンセルするようにしています。 BeginReadの返り値を保存。キャンセルしたい場所でEndReadの引数に渡すようにしているのですが、EndReadを呼び出すとそのままだんまりです。 なので、なにか手順でもあるのかと思い、検索をかけたのですが解決法がわからないため、ここで質問しました。 >Windowsサービスから直接タスクトレイに表示する事が出来ない サービスの登録で「デスクトップとの対話を許可」してあれば表示出来ますよ? 送信がちゃんと動いてるならそこ変える必要なんてないし 送信と別に受信用の接続つくれば解決するんじゃ >>813 .NET 5 ではサポートされないと、どこかで読んだ覚えが・・・ 参考になるWebPage等あれば教えてください。 直接やった方が単純なので・・・ Windows 管理ツール → サービス サービス名で右クリックしてプロパティ → ダイアログ → ログオン 「デスクトップとの対話をサービスに許可」にチェック HKLM\\SYSTEM\\CurrentControlSet\\Control\\Windows\\NoInteractiveServices 0にする必要があるかも >>816 教えていただきたいのは設定の方法ではなく、.NET 5のServiceWorkerでタスクトレイにアイコンを表示する方法です・・・ さすがにサービス作るのは面倒だから同一プロセス内で試しただけだけど BeginRead中に普通にWriteできたよ NamedPipeXxxStreamをnewする時にPipeOptions.Asynchronous指定してる? >>818 していませんでした。 サーバ、クライアント双方にオプションを指定し、Stream.Read中にStream.Writeが可能なことを確認しました。 ありがとうございます。 前提をすっ飛ばすと突拍子もない解決手段を思いつきそれを実現しようとしてしまい四苦八苦する典型例みたいですね レジ袋有料化みたいな話だね ただ、批判する意図はないけど、位置の概念がないストリームなら普通「全二重」であるはずだ、 ってのはちょっと考えれば気づけたはずじゃなかなとは思う 出来ることを出来ないと思い込んじゃったとこから始まってるんだな。 サービスからのタスクトレイアイコン然り、Streamのリードライトも然り。 >位置の概念がないストリームなら普通「全二重」であるはずだ お前の勝手な思い込みだとしか思えん >>822 その方法で判断してるなら既にいくつかバグ孕んでそう r/wを排他的にせざるをえない必然性や制約が存在しない限りわざわざ排他的にする合理性はないというだけの話。 馬鹿じゃないの。 というか、例えば2.0までのUSBは物理層が「半二重」だが、上位の層ではそんなことを 意識する必要はないようにしてある。 そんな制約を意識する必要があったらやってられないからだ。 必要もないのにそんな制約を課す馬鹿がどこにいる 双方向に通信できるか、一方向にしか通信できないことと、全二重半二重は別の概念じゃない? 双方向通信になって初めて半二重なのかと考える必要があるし、そもそもIPCをOSのAPIで使ってるときにそんなにシビアに考えることかな?という気がする 双方向のプロセス間通信なら、パイプじゃなくてIPC使ったほうが楽じゃね? >>825 お前の言う「普通」はお前の思い込みだって指摘だが、普通が読めないとかどっから出てくる話だ そもそも位置の概念と双方向か片方向かは関係ないし 双方向のストリームは全2重であるべきだって意見なら理解しないではないが お前の希望が普通に実装されてるとは限らんのだよ 白鳥は普通白い、というのは全称命題(黒い白鳥はいない)ではない。 イキり馬鹿って本当に馬鹿で笑えるねw ファイルのように位置の概念があるストリームでは排他的にr/wされたら困るだろうw 馬鹿じゃなかろうかマジで 最近ヤフコメの規制が話題になってるけど、 webくんだりで他人に居丈高な態度を取る奴の動機の源泉(うだつ上がらない) なんて見え透いてるよねw 別にうだつ上がらないのは悪くないが(俺もそうだし) いい歳こいてそういう自分の動機を自覚できないのも、他人から自分がどう見えているかを 意識できないのもかなり痛々しいよねえw >>831 普通のファイルのシークしながらの読み書きなら困る、はわかるんだけど、 それを一般化して、位置の概念のあるストリームで「普通」成り立つべき性質なのかよくわからない。 後学のために、いい例を教えてくれないか? そもそもファイルストリームって(単一ファイルでは)双方向通信に使えるものじゃないから、 全二重という思い込みがよく分からないし ワッチョイ的にデッドロックの意味勘違いしてた人っぽいし 全般的に用語の使い方がいい加減な人なんだろうなと思った ファイルストリームって、追記モードで複数オープンされたファイル扱えないのか? 双方向のストリームなら、非排他的にアクセスされると困るという意見ならまあ理解はできる 排他的とか、自分以外のアクセスの話で、自分が全2重でアクセスできるかどうかとは無関係だがな >>837 なるほど 全2重/半2重から排他/非排他の話になってるのは 話をずらそうとしてるんじゃなくて自分の中でもちゃんと区別できてないのか >>837 俺が用語を正確に使ってないのでなく君に読解力がないだけじゃないのかな。 俺はファイルストリームは「半二重」だと言ってるんだよ。わざわざ括弧を付けて。 括弧を付けているのは全二重/半二重という用語は普通はストリームを対象にした 用語ではないからだ。 というか、「必要のない制約をわざわざ課す馬鹿っているんですか?」 っていうのが俺の主張の本質なんだけど、その辺も含めて文脈読めないにも程があるね。 ああ、ほんとに双方向か片方向かと全/半2重の区別がついてないのね 全二重と半二重は鉄道で例えれば単線と複線の違いだよ。 RS485通信は半二重通信になるけどな。 >>843 またそれか。 片方向の文脈であれば全二重/半二重の区別は意味を持たない。 区別がついてないのは君じゃないの。マジで大丈夫か だいたい双方向とか片方向とかいう話がどっから出てくるのw 意味がわからないよ だから、必要もないのにr/wを排他的にする制約を課す馬鹿っているの?って話をしてるんだけど 次の展開予想すると、>>843 みたいな人はたぶんそれでも片方向/双方向の違いに固執して 「片方向っていうのは片方だけが能動的にr/wすることをいうんだ」みたいな話になるんだろうねw だから、だから何だよw この文脈でそれ重要ですか? ああ、排他的ってのは自分自身からのリードとライトについて言っているのか つまりお前の中では、全2重=非排他的 半2重=排他的 ってことなのね で、片方向っていうのは片方だけが能動的にr/wすること だと まあこれからも独自路線を行ってくれ。できればひっそりと ファイルストリームに半二重ないやろ? 途中で方向変わるのか? 全二重もないし。 誰かこいつらの脳幹をdisconnectしてくれや >>847 既に定義された用語と違う独自用語使うならスレ外でやれ デッドロックがどういう状態かの理解はできたか? 海外の機関車のハンドルとかについている装置 運転手が突発性の病気で倒れたりして手を離すと緊急停止する >>853 それは Dead man's switch >>852 いい機会だから言っておくか。 それは違う。 言葉というのは置かれた文脈によって意味が変わる、 という中学生でも知っている事実を君が知らないだけじゃないの? だいたい文脈無視して意味不明な用語法の問題にすり替えて、 それを指摘されてもまだ「おかしいのはお前だ」と言い張る神経が俺には理解できない。 どうでもいいけど技術的なやり取りをするのに言葉の意味を明確に定義せずにするのは困難しか産まないと思うけどな。 独自用語でもちゃんと定義したらよろしい。 定義なしに文脈によって意味が変わるなんて言ってるのは技術者失格。 えっちょっと待って IT用語としての「デッドロック」なんて基本情報レベルな単語だしこの板に書き込むような人なら常識だと思ってたんだけど >>801 なんかはてっきりギャグとして書いてるか、さもなくば デッドロックって言葉の意味を知らない人を馬鹿にするためにわざと書いてると思ってたんだが ひょっとして本当に知らなかったの?? でもって無知を恥じるでもなく「読解力」とか言い出して責任転嫁してるの? 「ボクチャンわるくないもん、読み手が馬鹿なのが悪いんだもん」って言ったところで 馬鹿をさらしてる人が言い出したところで説得力ないと思うよ そのうえさらに自分の語用・論理展開が支離滅裂なのを棚に上げて「文脈」とか言い出して正当化してもなあ >それを指摘されてもまだ「おかしいのはお前だ」と言い張る神経が俺には理解できない。 その言葉を反芻すべきなのは>>857 だと思うよ 文脈無視して意味不明な用語法ってか さすが自分の常識は絶対だって自信がある人はちがうな で、技術論を人格攻撃で逃げようってか 相手してられん お前らそろそろ落ち着きませんか? c#10の話でもしようぜ(錯乱) 特定の会社なりグループなりの小さなコミュニティ内で本来の定義とは異なる意味で用語が使われることはある そのコミュニティ内で齟齬なく意思疎通取れてるならまぁ問題ない ただその輪から出たら本来の意味でのみ使用すべきだし誤解を招きそうなら補足を入れるなりすればいい 定義にシビアなことが求められる技術者がこういう場で文脈によって変わるとか言っちゃうのはどうかと思う こういう場というのが便所の落書きじゃん、というなら否定はできんがw みんなわかっているくせにいつまでも指摘しないのな。 デッドロックは暗礁でも座礁でもない。壊れた錠前のことだ。 https://www.nhk.or.jp/bunken/summary/kotoba/gimon/170.html IT 用語では、並列処理時に異なるプロセスが、互いが専有するリソースの解放を求めて睨み合い、うごけなくなってしまうリソース競合のことだ。それ以外の意味はない。 一般用語に行き詰まりという意味があったとして、IT 用語としてリソース競合という意味のズバリの状況定義があるのだから、IT に正しい理解がある人間なら、行き詰まりという一般的な意味でこの語を IT 関連の説明に使うことは絶対に避ける。他人に誤解させるし、伝わらないし、紛らわしいのが目に見えているから。 色々な意味で、非常に恥ずかしい部類の誤用。強弁もたいがいにしておくべき。 >>865 壊れた錠前とかそういう比喩でなく、 膠着状態を指す英単語だよ a situation in which a disagreement cannot be settled. そもそもdead rockなんて勘違いしてる奴いないじゃん 座礁って言葉使ってる奴はいるけど身動き取れなくなると説明付き リソース競合ってまた狭い意味だし座礁と同じで狭い意味でデッドロックを使ってる デッドロック(IT限定)でもプロセス競合のほうがまだまし しかも競合それ自体には行き詰まりの意味はない あくまでも競合による行き詰まりがデッドロック 座礁がdead rockからきた勘違い deadlockは身動き取れなくなるという意味はない 語源はdead+lockだから「壊れた錠前」であってるけど 今はその意味で使われることはない >>870 座礁もdeadlockで間違いないし、rockとの勘違いでもない ただ英単語としての意味とIT用語としての意味を混同していたことが問題なだけ たんなるウェイトとデッドロックの区別がついてないバカがうだうだ言ってるだけ >>865 壊れた錠前では無いよ。 行き詰まりそのもの。 リソースのlock自体、錠前のことではない。 名詞としてのlockは、カギで開け閉めするものに限られるので、リソースなどを指してない。輪留めとか、にっちもさっちもいかない状態とかそういうのを指す。 動詞としては、固定するだよ。 リソースを取得するのにカギが必要なら錠前だろうけど、カギは要らない。 >>871 Pope Francis urges end to migrant boat deadlock https://www.bbc.co.uk/news/world-europe-46777844 ↑この船は座礁してるのかな? 多義語を知らない>>875 辞書引くだけで良いのに引けないんだね >>876 座礁って書いてある辞書教えて そしたら納得するよ >>877 納得はいらんけど、deadlockの自動詞、他動詞の意味調べてみ >>878 低頓する、低頓させる、「交渉は賃金問題で行き詰まった」、旺文社シニア英和辞典 行き詰まる、行き詰まらせる、低頓する、低頓させる、研究社リーダーズ英和辞典 さすがに「言葉の意味は文脈に依存する」ってことを知らない人がこれだけ多いと日本の将来心配になるねw この業界でデッドロックと言えば普通は非同期処理の文脈におけるデッドロックのことを指す、 これは最初から言っているように間違いない。 ただ必ずそうとは限らないと言ってるだけ。 イキってる皆さんがどう思おうが自由だけど、メソッドが制御を返さない状態のことをその原因を問わずに 「デッドロック」と呼ぶ用法は普通に使われてる。 そもそもデッドロックの意味とか、片方向と双方向の違いがどうのとか、そんなのどーでもいいわw 誰がそんな話してるんだよw 俺は時々ニュース系の板とかでネトウヨ馬鹿にして楽しませてもらってるけど、 この追いつめられると別の矮小な問題にすり替えて誤魔化して逃げるやり方って 連中そのものだねw >メソッドが制御を返さない状態のことをその原因を問わずに「デッドロック」と呼ぶ まあ、たんなるロック待ちをデッドロックというやつはたまにはいるけどな あきらかに間違ってるわけで、それが普通とかもう話にならん >追いつめられると別の矮小な問題にすり替えて誤魔化して逃げる まさに今のお前だな >>878 名詞が動詞化したものだから意味に違いはないよ 自動詞は「デッドロックになる」こと 他動詞は「デッドロックをもたらす」こと デッドロックとは「相対する2つの勢力が拮抗して事態が進展しない状態」 DBMSのデッドロックも非同期処理のデッドロックも状況が特化してるだけで意味は同じ 座礁は船と岩礁の力が拮抗してるってことなら その辺に転がってる石ころもdead rockだね >>884 deadlockの言う座礁する、座礁させるは日本語では比喩的な使われ方をする座礁だよ 交渉が座礁するとか交渉が暗礁に乗り上げるって意味での座礁 だから名詞じゃなく自(他)動詞 つまりデッドロックマンは何もかも間違ってると言いたい >>885 「deadlockの言う座礁する、座礁させる」って何? どこから出てきたの? deadlockの言う? 交渉が座礁するとは日本語では言わない 交渉が暗礁に乗り上げたとしてもそれがデッドロックとは限らない 単なる待ち状態をデットロックと言ってるのと同じレベル >>887 少なくとも英辞郎には暗礁に乗り上げるって意味が載ってる 意味として膠着状態を指す慣用句としての暗礁に乗り上げるが使われてる >そもそもデッドロックの意味とか、片方向と双方向の違いがどうのとか、そんなのどーでもいいわw >誰がそんな話してるんだよw >追いつめられると別の矮小な問題にすり替えて誤魔化して逃げるやり方って連中そのものだねw まさにこれ 話を逸らすついでにスレ流して汚点を忘れさせようとしてるのが観える >>891 東大話法、てのが大昔流行っていましたね ニコニコ弾幕ツールを作りたくてプログラミングとC#を初めて触ったのですが なにか参考になる動画や書籍資料等ないでしょうか? 簡単なメニュー程度なら作れるようになったんですがどうすれば弾幕打てるツールになるのか全く分かりません。 弾幕ツールソースとかでググってもそれっぽいのが全く出ず… 超初心者スレでも聞いたのですが回答もらえなかったのでこちらで… >>894 ぐぐるんなら、「ニコニコ動画 コメント api」とかじゃね? ちょっと古いけど ttps://qiita.com/tor4kichi/items/74939b49954d3e72d789 こんな感じで以前は出来ていたようです が、今春にコメントサーバーがリニューアルされているようなので、おそらくは上記の記事そのままではなくなっていると思います https://blog.nicovideo.jp/niconews/141893.html ブラウザコントロール上でアレコレさせるのとどっちが楽かは知らん いずれにしても、言語そのものの知識以外の、httpだとかニコニコの仕様そのものだとかの知識の方が必要かと思います 勉強のためにやりたいのなら別だけど・・・・ 自分で使いたいとかそういう目的なら、ほとんど完成品みたいなものが既にある https://www.nuget.org/packages/NicoNico.Net/ >>895-896 回答ありがとうございます C#の知識だけじゃ実現できないのですね(;´Д`) C#の他にJavascriptとかCのAPIですか…3,4年はかかりそうですね… やったことが無駄にならないことが分かったので頑張ります 日にどれくらい時間かけるかにもよるけど早い人なら無学から始めても1ヶ月かからんやろ すでにほとんど完成品といえるようなパッケージがあるならなれてる人なら1日かからず完成する 始めて開発というものをするにあたって半年以上かかりそうなもんはモチベーション続かんから普通はおすすめできない もしこのコメントツールで年単位で掛かりそうだと感じたならもっと規模の小さい、長くても1ヶ月くらいで完成させられるかな?って想像できるようなものから始めたほうがいいと思うよ >>894 10/20にニコニコ動画関連総合ツールスレで質問して回答もらえなかった人? そこまでできるようにはなったんだ ニコ動の弾幕なのか、ニコ生の弾幕なのかわからないけど ・ネットアクセスのやり方(httpclientかなんか) ・WebSocketの使い方(ニコ生のみ) ・jsonの知識 ・非同期の使い方 はわかってないとできないと思う 以下を見て理解できるまでがんばって。以下のニコ生・ニコ動の説明は古くてそのまま使っても動きません。 ブラウザーのディペロッパーツールで解析してね。 ニコ生 https://qiita.com/tor4kichi/items/5c438aa11fea5422103b https://qiita.com/tor4kichi/items/4df5b11ec564bb8f8d16 ニコ動 https://qiita.com/tor4kichi/items/91550a71119f3878bfba ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる