Thread Rating:
  • 640 Vote(s) - 2.79 Average
  • 1
  • 2
  • 3
  • 4
  • 5
マルチスレッド・マルチコアへの対応について
09-05-2011, 04:10 PM,
#7
RE: マルチスレッド・マルチコアへの対応について
回答、ありがとうございます。
(09-05-2011, 02:00 PM)hokada Wrote: ヘルプドキュメントは、IDEに入っている「Curl IDEドキュメント」です。キーワードは、前の返信でも書きましたように「サブアプレット」とか、実際のクラスである「AppletData」などで引っかかると思います。
使用しているのはCurl5.0なのですが、これでは「サブアプレット」というキーワードは引っかかりませんでした。
「AppletData」は掛かりました。まずはこれを読んでみます。
Quote:う~ん?申し訳ないですが、何をしたいのかよくわかりませんが、メモリ共有ができないと実現できないアプリケーションがあるのであれば、利用することはできないかもしれませんね。また、非常にスピードが遅いということがあれば、それはまた改善すべき別問題ですね。

開 発当初の設計思想がどうだったかはハッキリとは認識していませんが、「疑似的なマルチスレッド」ではなくサブアプレットという別機能を提供していると思い ます。メモリ共有をさせないという仕様も、例えば、開発者のミスなどでクラッシュを引き起こすのを避けるためだと思います。(あくまで想像です が・・・。)そういう意味ではメリット(?)になるかもしれないですね。

バックグラウンドタスクAPIは、確かに疑似的っぽいAPIかもしれませんが・・・。
伝わっておらずすいません。
「何がしたい」というのではありません。どちらかというと「何が出来るか?出来ないか?」です。

元々、Curlの思想としては「リッチクライアント」であり、これは「ファットクライアント」(例えばEXEなど)と
「Webクライアント」(ブラウザベース)のいいとこ取り、を目指して作られたものと理解しています。

私は元々ファットクライアントを作成してきた人間なので、それと比較して「何が出来るか?何が出来ないのか?」
「どう違うのか?違わないのか?(例えば速度など)」を知りたいのです。

私が以前に某Curlの技術者に聞いたところ「基本的にスレッドを作成できない」との回答だったので
「・・・って事はマルチコアの恩恵って無理じゃないの?」と感じ、この質問となった次第です。

しかし今回「似た様な事が出来る(ただし多少の制約はある)」との回答だったので
「じゃぁ基本的に上位設計の思想としては同じと思って良い?」と思い「ユーザレベルでのメリット・デメリット」
をお聞きしました。

とはいうものの、同一の事を行うアプリをWindowsFormプラットフォームで、仮に作った場合と比較すると
明らかに遅い部分が見受けられます。ということは、今までと同じ感覚で上位設計を行うと、実用上問題が
出る可能性が非常に高い事になります。

これがなぜ起こるのか?が分からないため、それをプラットフォームの特性から探っている次第です。
(その一つの要因として「もしかしてマルチスレッドが関係あるのか?!」と思ったのが質問のトリガーです)


Messages In This Thread
RE: マルチスレッド・マルチコアへの対応について - by 復活の帝王 - 09-05-2011, 04:10 PM
Forum Jump:


Users browsing this thread:
1 Guest(s)

MyBB SQL Error

MyBB has experienced an internal SQL error and cannot continue.

SQL Error:
1017 - Can't find file: 'mybb_threadviews' (errno: 2)
Query:
INSERT INTO mybb_threadviews (tid) VALUES('257')