[過去ﾛｸﾞ]
マルチスレッドプログラミング相談室 (986ﾚｽ)
マルチスレッドプログラミング相談室 http://toro.5ch.net/test/read.cgi/tech/997345868/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
736: デフォルトの名無しさん [] 02/11/12 19:32 Windowsであるクラスに参照カウントを持たせ、InterlockedIncrement./InterlockedDecrementで マルチスレッド対応にしようとしたのだが… void ref() { InterlockedIncrement(&m_ref); } void release() { if (InterlockedDecrement(&m_ref) == 0) { delete this; } } ところが、delete thisの直後にref()が呼ばれると、m_ref自体が解放された領域にあるため、 とんでもない値になってしまう。参照カウントをメンバー変数にするのが間違い? どうしたらいんだろう？マルチスレッドのエキスパート様の降臨おながいします http://toro.5ch.net/test/read.cgi/tech/997345868/736
739: 736 [] 02/11/12 21:18 ある時点で、m_ref>0だったとします。 2つのスレッドが、それぞれ同時にref()とrelease()を呼び出すと… http://toro.5ch.net/test/read.cgi/tech/997345868/739
741: 736 [] 02/11/12 21:35 void ref() { EnterCriticalSection(&m_cs); InterlockedIncrement(&m_ref); LeaveCriticalSection(&m_cs); } void release() { EnterCriticalSection(&m_cs); if (InterlockedDecrement(&m_ref) == 0) { delete this; } LeaveCriticalSection(&m_cs); } としても、ref()でInterlockedIncrement()にたどり着いたときには… http://toro.5ch.net/test/read.cgi/tech/997345868/741
744: 736 [] 02/11/12 22:36 refが参照カウントを増やす(objectを貰って来る)ためのものなのだが… http://toro.5ch.net/test/read.cgi/tech/997345868/744
746: 736 [] 02/11/13 10:05 いやCOMじゃなくて。 あるオブジェクトのインスタンスが作られるとm_ref=1となっていて、 そのオブジェクトを例えば別のスレッドが使うためにコピーを作るとm_ref=2 となる。 まさにその瞬間に、インスタンスの元のホルダーがオブジェクトを破棄しようとすると、 m_refのインクリメントとデクリメントが同時に起きる。 Interlocked...は同時じゃないが、ref()とrelease()が同時に呼ばれrelease()を 実行しているスレッドの方が早くCriticalSectionを獲得して解放したのち、 InterlockedIncrementが呼ばれると、解放されてしまうので値が不定になってしまう。 http://toro.5ch.net/test/read.cgi/tech/997345868/746
752: 736 [] 02/11/13 12:37 >746 やっぱり、そういう事になりますか。 >749 それは、ちっとも解決にならない。 method2がこの場合ref()なわけで、ref()から戻ったら、そのオブジェクト使おうと するんだから。 >750 参照カウントは、扱われるインスタンス内に有りますが、 そのインスタンスを指すスマートポインターのようなクラスで持たなきゃならないって 事ですか? そうでなくて、インスタンスと別にアロケートして参照カウント作ってもだめって事だけ? >グローバルなオブジェクトや静的なオブジェクトを参照カウントでやろうとしてるような気もするし。 流石に、そんなこたぁない。 http://toro.5ch.net/test/read.cgi/tech/997345868/752
757: 736 [] 02/11/13 17:30 なんか昨日から粘着が居るが >753 >分からんヤツやな、、、 あんたほどでは（Ｗ >refする前に、oobjectが生きてて、refできるか確かめないかんやろ。 確かめた時生きてても、じゃあ参照しようとしたら死んでる罠 確かめるときに参照かうんと増やす何て言うなよ（Ｗ >755 >参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかってる? それは当然ですね。 >これは本来アトミックな処理なので、別スレッドに渡すってのも 別のスレッドに渡すのではなく、 あるスレッドAが参照カウントを持つOのインスタンスをつくって、 別のスレッドBがそのオブジェクトをもらおうとしたらば、 Aはもう要らないとOを破棄しようとしている最中だったわけです。 http://toro.5ch.net/test/read.cgi/tech/997345868/757
760: 736 [] 02/11/13 18:22 >「渡す」つってんのはインスタンス自体じゃなくて参照のことをいってんだけど。 >ポインタといったほうがいい? 「渡す」というのは、あるスレッドAがインスタンスOの参照(カウントが増えた状態)を、別のスレッドB がアクセスできるようにするという意味で使いました。 そうではなくて、スレッドAの預かり知らぬところで、スレッドBがインスタンスOを コピー(の過程で参照化運とは増える)して使おうとするということです。 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた わけです。 >758 そういうなら、参照カウント使ったクラスうｐしてみそ。逃げますか？（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/760
763: 736 [] 02/11/13 19:03 そんなに広い範囲でロックかけないで済む方法ってないの? http://toro.5ch.net/test/read.cgi/tech/997345868/763
767: デフォルトの名無しさん [sage] 02/11/13 21:20 >>736 参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、 ref を呼び忘れてる。 参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、 それは通常の参照じゃなく、弱い参照だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/767
768: デフォルトの名無しさん [sage] 02/11/13 23:15 >>736 そもそも、スレッドが生きているかどうか分からないオブジェクトへの ポインタを受け取ること自体に問題があるような。まさか、 スレッドA: p = new クラス(); Bに渡す(p); p->release(); スレッドB: p = Aから受け取る(); p->ref(); というコードを書いていないだろうな？もしそうなら構造上の問題。 Bから見える場所にpを格納したなら、その分の参照カウントを数えなくては ならない。それって本質的にはシングルスレッドでも同じことだけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/768
783: 736 [] 02/11/14 10:50 どうして、参照カウントが増えた後の話にしたがるのか… http://toro.5ch.net/test/read.cgi/tech/997345868/783
787: 736 [] 02/11/14 11:26 >>773 > そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って > カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し > てしまうというのはバグ。 はぁー。 受け取る処理ってどうやるのさ? >774 これからよく読んでみます。 ありがと。 http://toro.5ch.net/test/read.cgi/tech/997345868/787
789: 736 [sage] 02/11/14 11:34 O1は、スレッド間で共有しているリスト中の要素としてある。 O2=O1は、そのリストから目的の物を検索して取り出す処理の中。 http://toro.5ch.net/test/read.cgi/tech/997345868/789
794: 736 [sage] 02/11/14 12:31 >791 >その前にThread Bがリストの要素への参照を持ってるなら >参照カウントは2になってなきゃおかしい。 リストの要素への参照とは? O1がそれだと言っているのか（Ｗ >793 >で、この get と remove はロックを使わずやりたいと。 >そういうことか？ そう。 でも、 >「排他制御せずにリストにアクセスしたら、変になるんですけど。」 という事じゃない。 removeで要素中のO1は削除されるけど、Thread BがO2を手に入れていれば O1-+ +-->ref:2,data:"ABC" O2-+ から O2---->ref:1,data:"ABC" となり、他のスレッドは、もはやこのデータにアクセスできないが、 Thread BはO2から使える。O2が不要になって破棄したら、データ本体も解放される。 http://toro.5ch.net/test/read.cgi/tech/997345868/794
800: 736 [sage] 02/11/14 21:27 >796 未だに問題のポイントがわかってない言語障害者が居ますね。 >797 やっぱり、そうなっちゃいますかね。 >799 COMは関係なかろう、STAならInterlock何かする必要無いし、 そうでなければ、COMでも同じ。 http://toro.5ch.net/test/read.cgi/tech/997345868/800
804: デフォルトの名無しさん [sage] 02/11/14 22:20 >>736 考え方おかしいよ。 管理する側とされる側がごっちゃになってる。 そもそもdelete後に破棄されたインスタンスの排他制御 オブジェクトを参照しようとしてる事をおかしいと思わないの？ http://toro.5ch.net/test/read.cgi/tech/997345868/804
809: 736 [sage] 02/11/15 10:43 >804 頭おかしいよ。 こんなのどこにでもある。見たこと無いのか? http://toro.5ch.net/test/read.cgi/tech/997345868/809
810: デフォルトの名無しさん [sage] 02/11/15 10:55 >>736 何人もの人間が否定してるんだから、おかしいのはお前だろ(笑 http://toro.5ch.net/test/read.cgi/tech/997345868/810
811: 736 [sage] 02/11/15 11:23 じゃあ、COMもおかしいのか? http://toro.5ch.net/test/read.cgi/tech/997345868/811
813: 736 [sage] 02/11/15 12:24 >812 >つーか、教えを乞う立場だったら、もっと謙虚になれ。 共有しているオブジェクトの集合に丸ごとロックかけずに、 各オブジェクトの参照カウントだけで済むかがポイントなのに、 参照カウントのインクリメント不足だとか、 COMを知ってればとか、 おんなじ事 おんなじ事 おんなじ事 おんなじ事 ばかーーーり。 しつこつ しつこく しつこーーーーく 同じこと繰り返す粘着が多くてウンザリ。 getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。 参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。 じゃあ、参照を手に入れる処理を書いてみろというと、とたんに逃げ出す。 どうしてポイントがずれた香ばしい奴が多いのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/813
814: 736 [sage] 02/11/15 12:26 >812 >「どこにでもある」 が 「おかしくない」 の理由には全然ならない事に気付け。 >つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな >サンプルに見舞われてるんだな。 これ見たこと無いか? static ULONG WINAPI Increment(LPLONG p) {return InterlockedIncrement(p);} static ULONG WINAPI Decrement(LPLONG p) {return InterlockedDecrement(p);} ULONG InternalAddRef() { return _ThreadModel::Increment(&m_dwRef); } ULONG InternalRelease() { return _ThreadModel::Decrement(&m_dwRef); } STDMETHOD_(ULONG, AddRef)() {return InternalAddRef();} STDMETHOD_(ULONG, Release)() { ULONG l = InternalRelease(); if (l == 0) delete this; return l; } まあ、君のコードの中では、 static ULONG WINAPI Increment(LPLONG p) {return ++(*p);} static ULONG WINAPI Decrement(LPLONG p) {return --(*p);} しか使われないと思うが（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/814
816: 736 [sage] 02/11/15 12:40 それで？ http://toro.5ch.net/test/read.cgi/tech/997345868/816
818: 736 [sage] 02/11/15 12:44 738 ：デフォルトの名無しさん ：02/11/12 20:25 参照カウントを0から始めたに100スレッド 740 ：デフォルトの名無しさん ：02/11/12 21:24 ref() と release() が互いに排他してなきゃ動くわけないじゃん。 742 ：デフォルトの名無しさん ：02/11/12 21:57 あるオブジェクトに触れるスレッドが一つふえたら そのオブジェクトの参照カウントをageておく必要があることに 気づいてないに1000はらたいら 743 ：デフォルトの名無しさん ：02/11/12 21:58 ＞739 それもなんだかおかしな動作だな。 refを発行する、というのは、どっかからobjectを貰ってきてるわけだろ。 で、releaseを発行するということは、所有権の一端を持っているわけだよな。 それで、deleteが実行されるというのは、 「refcount == 0かもしれないobjectが渡ってきた」 「release発行しすぎ」 ってなわけだろ。refするタイミングとか、考え直した方がいいんでないか？ 745 ：デフォルトの名無しさん ：02/11/12 22:52 736はひょっとしてCOMを知らない？ 747 ：デフォルトの名無しさん ：02/11/13 10:35 「別のスレッドが使うためにコピーを作る」ときに 「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。 「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。 http://toro.5ch.net/test/read.cgi/tech/997345868/818
819: 736 [sage] 02/11/15 12:44 750 ：デフォルトの名無しさん ：02/11/13 11:21 ひょっとしてrefcountをさらにポインタや参照で管理しようとしてないか? そんなのrefcountの意味が全くないぞ。根本的にrefcountについて誤解してるだろ。 751 ：デフォルトの名無しさん ：02/11/13 11:28 >>750 俺もそんな気がして来た。グローバルなオブジェクトや静的なオブジェクトを 参照カウントでやろうとしてるような気もするし。 753 ：デフォルトの名無しさん ：02/11/13 15:40 分からんヤツやな、、、 refする前にreleaseが発行されてrefcount==0になる 可能性があるなら、refする前に、oobjectが生きてて、 refできるか確かめないかんやろ。その結果、objectが 死んでるなら、refしてobject渡すのは諦めなアカン。 で、そこでobjectが死んでるのが間違いなら、releaseか refの発行の仕方がオカシイんや。 http://toro.5ch.net/test/read.cgi/tech/997345868/819
820: 736 [sage] 02/11/15 12:45 767 ：デフォルトの名無しさん ：02/11/13 21:20 >>736 参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、 ref を呼び忘れてる。 参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、 それは通常の参照じゃなく、弱い参照だ。 769 ：デフォルトの名無しさん ：02/11/13 23:23 > あるスレッドAが参照カウントを持つOのインスタンスをつくって、 COM知ってさえいれば・・・ 772 ：デフォルトの名無しさん ：02/11/13 23:58 なんか皆さん盛り上がってますが… >>745 >>769に同意。 リファレンスカウントのサンプルを見たければCOMを勉強すればよい。 それと。日本語で一所懸命書かれてもどうにも伝わりにくいようですな。 C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。 773 ：デフォルトの名無しさん ：02/11/14 00:03 >>760 > 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを > (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた > わけです。 そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し てしまうというのはバグ。 http://toro.5ch.net/test/read.cgi/tech/997345868/820
822: 736 [sage] 02/11/15 12:51 君らのしつこさを確認させてやっただけだよ http://toro.5ch.net/test/read.cgi/tech/997345868/822
824: 736 [sage] 02/11/15 12:58 結局誰も判らんのか。それならそう言えよ無能者ども。 http://toro.5ch.net/test/read.cgi/tech/997345868/824
827: 736 [sage] 02/11/15 13:07 まだ言ってるのか。 >参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 >してないのはシングルスレッドを前提にしてる場合だけ。 >わかった? void ref() { EnterCriticalSection(&m_mutex); InterlockedIncrement(&m_ref); LeaveCriticalSection(&m_mutex); } void release() { EnterCriticalSection(&m_mutex); if (InterlockedDecrement(&m_ref) == 0) { delete this; } LeaveCriticalSection(&m_mutex); } としたら満足か？（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/827
828: 736 [sage] 02/11/15 13:09 >826 おまえ、InterlockXXってなんのためにあるのか知らんだろ。 知らない奴に限って、無駄なレスを返しやがる。 http://toro.5ch.net/test/read.cgi/tech/997345868/828
831: 736 [sage] 02/11/15 13:21 >>836 あのなあ、 >>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 >>してないのはシングルスレッドを前提にしてる場合だけ。 >>わかった? というのは読めないのか。お前は、自然言語にたいする理解力は０だな。 ロックかけなきゃだめだと言ってるやつがいるから、ロックしたまで。 なーんの解決にもならんし、もともと、Interlockしてるから不要なんだがな。 http://toro.5ch.net/test/read.cgi/tech/997345868/831
832: 736 [sage] 02/11/15 13:21 >830 だわ http://toro.5ch.net/test/read.cgi/tech/997345868/832
833: 736 [sage] 02/11/15 13:23 で？８２６も逃げたのか。全く都合が悪くなると逃げて…自分の発言に席にもてよ。 どうせ、別人のフリしてまた別の事言い出すんだろうが http://toro.5ch.net/test/read.cgi/tech/997345868/833
834: 736 [sage] 02/11/15 13:26 ん？deleteまではロックしなきゃダメかな。 まあ、どのみちref()でロック獲得したときに、解放済みというのは避けられんが。 http://toro.5ch.net/test/read.cgi/tech/997345868/834
836: 736 [sage] 02/11/15 13:34 やっぱり、List::get()でリストの検索処理が丸ごとロックするしかないのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/836
838: 736 [sage] 02/11/15 13:49 それ以外に無いのか聞いてんだが。 ここのいる連中じゃ無理のようだ（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/838
839: 736 [sage] 02/11/15 13:53 >812 >「どこにでもある」 が 「おかしくない」 の理由には全然ならない事に気付け。 >つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな >サンプルに見舞われてるんだな。 ８１２も逃げたようだな。逃げ足の速い連中だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/839
845: 736 [sage] 02/11/15 15:06 >840 またバカが湧いてきた。 >散々いわれてんのに。>>762とか>>785とか。 >762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？ リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。 君のような厨には理解で菌だろうがな。 >大体間接的に渡すって話自体>>789くらいでいきなりだし。 間接的?ハァ?頭大丈夫? 785は俺だ。 たくっ。ろくに読まないでレスするアホウは書くなっつの。 >いつまでも君の相手してらんないしね。 >漏れもそろそろ出かけなきゃならないんでバイバイ。 いや、君みたいなアホウに相手してくれとは言ってないから（Ｗ お呼びでないの（Ｗつか出てくんなっての 大体、レスして何か言われたら自分が誰かわかるように名前に番号入れるもんだろ。 言いっぱなしで自己満足してる厨が多すぎ。 http://toro.5ch.net/test/read.cgi/tech/997345868/845
846: 736 [sage] 02/11/15 15:16 740 ：デフォルトの名無しさん ：02/11/12 21:24 ref() と release() が互いに排他してなきゃ動くわけないじゃん。 826 ：デフォルトの名無しさん ：02/11/15 13:03 >>813 > 共有しているオブジェクトの集合に丸ごとロックかけずに、 > 各オブジェクトの参照カウントだけで済むかがポイントなのに、 参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 してないのはシングルスレッドを前提にしてる場合だけ。 わかった? こういう連中は、 void ref() { EnterCriticalSection(&m_cs); ++m_ref; LeaveCriticalSection(&m_cs); } void release() { EnterCriticalSection(&m_cs); if (--m_ref) == 0) { delete this; } LeaveCriticalSection(&m_cs); } って書いてるのかな。馬鹿だなー。 こんな事言ってる奴が多いのは オ ド ロ キ。 もはや都市伝説だな。 http://toro.5ch.net/test/read.cgi/tech/997345868/846
847: 736 [sage] 02/11/15 15:17 おっ！ 830が、慌ててネットで調べ始めた。まあ、自分の馬鹿さ加減を思い知れ。 http://toro.5ch.net/test/read.cgi/tech/997345868/847
848: 736 [sage] 02/11/15 15:21 おっ！ 他にもInterlockだけじゃダメだと思ってる奴も多いな。 まあ、release()のLeaveCriticalSectionがdelete以降なのは論外だが、 void ref() { InterlockedIncrement(&m_ref); } void release() { if (InterlockedDecrement(&m_ref) == 0) { delete this; } } じゃだめだと思ってるやつは何か言ってみろ。 どうせ逃げんだろうけどな。 http://toro.5ch.net/test/read.cgi/tech/997345868/848
851: 736 [sage] 02/11/15 15:48 おいおい、本当にのこのこ出てきたよ。恥ずかしい奴だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/851
852: 736 [sage] 02/11/15 15:50 >しかし、危険性において 846 のコードは結局 848 と変わらないな。 説明してみろよ。わくわく。 Bのところに行くのは、どういう場合さ? http://toro.5ch.net/test/read.cgi/tech/997345868/852
856: 736 [] 02/11/15 16:03 あげてねーじゃん http://toro.5ch.net/test/read.cgi/tech/997345868/856
857: 736 [] 02/11/15 16:04 >855 リストである必要なし。 グローバル変数など共有してれば同じ。 この場合動的じゃなきゃ意味無いが。 http://toro.5ch.net/test/read.cgi/tech/997345868/857
861: 736 [sage] 02/11/15 16:13 m_csってメンバー変数じゃないのか? ref()のEnterCriticalSectionでブロックされてるときに deleteされるのは大丈夫か? 首尾よく、ref()でCriticalSectionに入れてもm_refは不定だぞ。 http://toro.5ch.net/test/read.cgi/tech/997345868/861
862: 736 [sage] 02/11/15 16:16 で？849はやっぱり逃げたのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/862
866: 736 [sage] 02/11/15 16:30 >865 と言うと? >864 おい！あるってぞ。言い返せよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/866
873: 736 [sage] 02/11/15 17:18 それは、16スレッドが同時に書き込めるのか? 各スレッドが別の要素にアクセスするとして。 リストが要素数なんか持ってても大丈夫? 単純なリストならまだしも、空リストとか管理されてると結局その中の 一つのスレッドしか書き込みできない(というか排他制御が必要な)気がするが。 http://toro.5ch.net/test/read.cgi/tech/997345868/873
881: 736 [sage] 02/11/15 21:01 お前ら無能すぎ。そんな程度で２ちゃん来てんじゃねーよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/881
885: 736 [sage] 02/11/15 21:13 >>881 とうとう偽者まで出てきたか。 http://toro.5ch.net/test/read.cgi/tech/997345868/885
886: 736 [sage] 02/11/15 21:13 適当ほざいてんじゃねーよ 帰って寝てろ ﾜﾗﾜﾗ http://toro.5ch.net/test/read.cgi/tech/997345868/886
887: 736 [sage] 02/11/15 21:16 881=882だろ。 >880 > 第三に、参照カウントも複数のスレッドから > 参照されるから、これも排他しなくちゃならないよね。 どういう風に?(W http://toro.5ch.net/test/read.cgi/tech/997345868/887
888: 736 [sage] 02/11/15 21:17 >886 おまえも881だろ。 >884=870 もうちょっと、説明してくれや。 http://toro.5ch.net/test/read.cgi/tech/997345868/888
889: 736 [sage] 02/11/15 21:18 騙ってまで何がやりたいんだか >880 教科書のコピペはやめようね http://toro.5ch.net/test/read.cgi/tech/997345868/889
899: 736 [sage] 02/11/15 22:02 >898 ギブアップしたの?(W http://toro.5ch.net/test/read.cgi/tech/997345868/899
926: デフォルトの名無しさん [sage] 02/11/16 07:53 なんでこんなくだらん事で話を引っ張ってるの？ ＞ >>736 http://toro.5ch.net/test/read.cgi/tech/997345868/926
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s