[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
526(1): デフォルトの名無しさん [] 2016/04/24(日) 12:13:06.27 ID:ynYywbEh(1/8) AAS
>>525デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。
529: デフォルトの名無しさん [] 2016/04/24(日) 13:02:46.55 ID:ynYywbEh(2/8) AAS
等と意味不明な供述をしており。
532: デフォルトの名無しさん [] 2016/04/24(日) 14:59:36.53 ID:ynYywbEh(3/8) AAS
俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。
こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、
当然のことながらリプライに遅延もない。
そこで案ずるよりも生むが易しというわけ。
Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。
533: デフォルトの名無しさん [] 2016/04/24(日) 15:05:02.69 ID:ynYywbEh(4/8) AAS
ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。
俺はこの経験から一つの予測を立てた。
これからのサービスは、C++で書かれるようになる可能性がある。
何しろ圧倒的に速い。
一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。
この事実に世の中が気づくにはそう時間がかからないはず。
そしてsystemdがこの動きを促進するはず。
ちなみにWindowsで書いてLinuxで動かしてます。
536: デフォルトの名無しさん [] 2016/04/24(日) 15:08:01.90 ID:ynYywbEh(5/8) AAS
Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。
Qt+systemd、この直観的な選択は大成功であった。
537: デフォルトの名無しさん [] 2016/04/24(日) 15:11:43.89 ID:ynYywbEh(6/8) AAS
Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。
systemd万歳！
538: デフォルトの名無しさん [] 2016/04/24(日) 15:16:24.95 ID:ynYywbEh(7/8) AAS
更にもう一つヒントがある。
複数のクライアントから多様なリクエストがあるとはいえ、一つのプログラムが擁する
データ構造などたかが知れているのだ。
クライアントAのリクエストにこたえるため使用された記憶空間は、解放されたのち
クライアントBのためにそのまま使われる可能性があるのだ。
そういったわけで断片化は気にする必要が無い。
若者よ、案ずるより産むが易しですぞ。
541: デフォルトの名無しさん [] 2016/04/24(日) 20:02:15.39 ID:ynYywbEh(8/8) AAS
むしろ、わからないのに何故、一生懸命主張していたのかと。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.046s