アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
プログラマから見ると (スコア:2, 参考になる)
1.
ほとんどの UNIX 系 OS はスレッド毎に異なる signal mask を持てるが、signal handler 自体はプロセスに1つです。 スレッド毎に signal handler を持てると、Windows の構造例外のように「__try の中で起きた signal は __catch 節でキャッチする」ようなプログラムスタイルが可能になるかも。
2.
スレッド固有の情報を指す専用レジスタを導入するようですね。
スレッド構造体 or Thread Local Strage (TLS) の開始ポイントなどを指すレジスタがあって、 ユーザープロセス側はそのレジスタを読めば 自分がどのスレッドか分かるというものだと 思われます
pthread_self API とか GetCurrentThread API を 呼び出す必要がなくなるし、 TLS へのアクセスが高速化されるので、 サーバーサイドのマルチスレッドプログラムが 高速化できますね。
ただ、その特定レジスタはユーザープログラム側で値を破壊しないようにする必要があります。 コンパイラ & ライブラリの変更も必要です。
でも 以前のバイナリとの下位互換性はどうするのでしょう?
OS かスレッドライブラリがプログラムのバージョン情報を取得して、スレッドレジスタを提供するかどうか変えるのかしらん? # x86 は FS レジスタが、すでにスレッドレジスタとして使われているからあまり関係ない?
コンタミは発見の母
Re:プログラマから見ると (スコア:1)
目的として、バイナリ互換もあがっていますね。多分、誰かが何とか
してくれるでしょう(笑)。まぁ冗談はおいておいて、どういう実装が
行われるのかが気になりますね。
Software ScelabilityのところでJavaの話が出てきているので、
簡単に使える、という点で意識しているようです。C++でも例外処理を
交えながら使えるようにするみたい。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:プログラマから見ると (スコア:1)
pthread格闘記
http://pantora.tripod.co.jp/pthread.html [tripod.co.jp]
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:プログラマから見ると (スコア:0)
Re:プログラマから見ると (スコア:0)