pthread地獄 part 2
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/12/20(水) 22:11:47徳の高い人はpthread天国でも可。
■前スレ
pthread地獄
http://pc8.2ch.net/test/read.cgi/unix/1010933537/
0083名無しさん＠お腹いっぱい。
2008/07/15(火) 09:21:07>>59の"Timed Wait Semantics"に挙げられた問題が存在する。
>>61をみると理解できていないようなので、何が問題なのかわかるまで考えた方がよいだろう。
プロセスのプリエンプション自体が問題なのではないので、絶対指定のPOSIXにはこの問題はない。
0084名無しさん＠お腹いっぱい。
2008/07/15(火) 09:25:58Cで頼む
0085名無しさん＠お腹いっぱい。
2008/07/15(火) 12:11:40pthread_xxx_npあたりでいいよ。
CASとかもセットで。
0086名無しさん＠お腹いっぱい。
2008/07/15(火) 15:46:11pthread_xxx_npあたりで頼む
0087名無しさん＠お腹いっぱい。
2008/07/18(金) 10:56:20サブルーチンをコンパイルする時って、どんなコンパイルオプションを
付ければ良いんですか？
普通に、コンパイルして共有ライブラリを作ればよい？
このサブルーチンの中では、pthread_XXXはコールしていないので、
#include <pthread.h> もしてないんですがこれってダメ？
008887
2008/07/18(金) 10:59:53大丈夫な様に作ってあります。
0089名無しさん＠お腹いっぱい。
2008/07/18(金) 14:33:31引数だけで計算して値を返すとか、完全に状態に依存しないものならね。
0090名無しさん＠お腹いっぱい。
2008/07/18(金) 15:12:22http://docs.sun.com/app/docs/doc/819-0390/compile-94179?a=view
これは-D_REENTRANT -lthreadと等価なようだ。
gccであっても、使っているライブラリによっては、同様に何らかのシンボル定義が
必要になるかもしれない。
0091名無しさん＠お腹いっぱい。
2008/07/19(土) 11:43:35return a + b;
}
でも？
0092名無しさん＠お腹いっぱい。
2008/07/19(土) 15:22:040093名無しさん＠お腹いっぱい。
2008/07/22(火) 12:01:15マルチプロセスだと、waitpid(2)とかで複数の子プロセスの終了を
待てるんですが、pthread_join()だと、特定のスレッドの終了しか待てません。
例えば、
１００個の子プロセスを作成して、親プロセスはwaitpid()で任意の子プロセスの終了を
監視していて、特定の子プロセスが死んだ場合に、そのプロセスの再起動(fork())を
行うという処理を、pthreadで書こうとした場合、どうすれば良いんでしょうか？
そもそも、上記の様な考え方は、プロセスの親子関係が前提となっているので、
この考え方を、親子という関係のないpthreadに持って来る事がおかしいのでしょうか？
0094名無しさん＠お腹いっぱい。
2008/07/22(火) 12:38:18勝手に死ぬなら、たまにpthread_kill(thread_id, 0)するとか。
009593
2008/07/22(火) 13:21:54捕まえるという動作ではないですよね。(ポーリングっぽい)
例えば、１００個スレッドを作って、その各スレッドがTCPソケットを使って
通信していて、TCPコネクションがcloseされたので、pthread_exit()を
コールしたとか、、ソケットから受け取ったデータを処理している最中に
SIGSEGVで死んだとかした場合に、これら１００個のスレッドを常に監視
していて、死んだスレッドを再度作成したいって感じの処理をすっきりと
書きたい場合ってどうやるんでしょう？
スレッドじゃなくてプロセスだったら、子プロセスがexit(2)した場合も、
子プロセスが、SIGSEGVで死んだ場合も、親プロセスがwaitpid(2)してれば
子プロセスが死んだタイミングで親プロセスはそれを知ることが出来るじゃ
ないですか。
これと同じような事をpthreadでやりたいんですが、なんかよく判らんのです。
0096名無しさん＠お腹いっぱい。
2008/07/22(火) 14:09:26無意味では？
そう考えていくと、スレッドが自発的に終了するケースだけを扱えばいいわけなので、
(スレッドプール的な構成なら)条件変数での通知・待機を使えばよさそうに思う。
0097名無しさん＠お腹いっぱい。
2008/07/22(火) 14:17:14必要もない。個々のスレッドは処理が終わったら終了するのではなく、次の処理要求
を待って休眠するように書く方がよいだろう。
009893
2008/07/22(火) 14:58:19>>97
確かに、SIGSEGVなどで死ぬ場合は、SIGSEGVを発生させたロジックを実行中のスレッド
のみが死ぬわけではなく、プロセス自体がいなくなりますが、これをハンドリングして
特定のスレッドのみを再起動して処理を継続するってのは変でしょうか？
プログラムのバグも含めて考えると、やっぱりスレッドがSIGSEGVするケースも考慮して
おきたんです。
Webサーバの様なプログラムをマルチスレッドで書くとすると、クライアントから送られて来た
データがメタメタでサーバ側の処理がSIGSEGVしてしまったとか。(だったらちゃんとデータを
処理する前にチェックしろってのは、ちょっと置いといて。)
こういったケースで正常なクライアントとのコネクションも全部潰れてしまうのは、なんだかなぁ
って思ったんです。
009993
2008/07/22(火) 15:06:19それと、スレッドの終了を待つってのがどうもうまく結び付きません。
例えば、
ワーカースレッドがもうダメポってpthread_cond_signal()をコール。
メインスレッドは、pthread_cond_wait()で待ってる。
ワーカースレッドはどのタイミングでpthread_exit()をコールすればいいの？
メインスレッドは、どのタイミングでpthread_join()をコールすればいいの？
ワーカースレッドが居なくなったタイミングって条件件数を使えばメインスレッドで
捕まえることって出来ますか？
なんか、この辺りがよく判らんのです。
0100名無しさん＠お腹いっぱい。
2008/07/22(火) 15:24:43にプロセスで書くのをお薦めする。Apacheでも普通に使われているのを見れば
わかるように、UNIXのプロセスはそれほど遅くない。
どうしてもpthreadで書きつつsignalが捕捉したいのなら止めないが、
"pthread地獄"のスレタイは伊達や酔狂ではないので。
0101名無しさん＠お腹いっぱい。
2008/07/22(火) 15:58:43SIGSEGVを発生させるようなことをしたスレッドを、どうやって特定する？
たぶん難しいと思うから、そんなの実装するよりは真面目に入力のチェックを
実装した方がずっと簡単だと思うけどなぁ。
内部だけで使うプログラムならいいけど、セキュリティ的にもあれだし。
0102名無しさん＠お腹いっぱい。
2008/07/22(火) 16:12:40いちおうSIGSEGVは「踏んだ」スレッドに飛ぶのでそれはわかる。
たぶん、正しくリソースを解放して終了するのが難しい。
010393
2008/07/22(火) 16:20:14>>101
ワーカースレッドとは別にsignalをハンドルするスレッドを、１つもしくは、
ワーカースレッド数分作成しておけば、どのワーカースレッドがSIGSEGV
を発生させたかは判るような気がしてます。
とりあえず、signalはちょっと置いといて、複数のワーカースレッドが
居なくなったタイミング(pthread_exit()をコールしたタイミング)で
メインスレッドがpthread_join()をコールする仕組み(=waitpid())を
作ってみたんですが、単純にpthread_cond_signal()をワーカースレッドで
呼ぶだけだと、メインスレッドがpthread_cond_wait()を実行中じゃない
ケースでとりこぼしちゃうんですね。
メインスレッドがちゃんとpthread_cond_wait()を実行しているタイミングを
ワーカースレッドが認識しないとダメなのか。
なんか、基本的な考え方が間違っている様な気がしてきました。
そもそも、pthread_join()が複数のスレッドを待てない時点で、この様な
事をやりたいという考えがそもそも変な気がしてるんですが、でも、
Windowsなんかのスレッドだと出来るらしいし。
0104名無しさん＠お腹いっぱい。
2008/07/22(火) 16:38:33別に間違ってちゃいかんというわけではないが、そっちは地獄方面。
0105名無しさん＠お腹いっぱい。
2008/07/22(火) 16:41:241:1な実装とかだと、踏んだスレッドにSIGSEGVが飛びそうなのは想像できるんですが、
それがどういうレベルで保証されてるか、もし知ってたら教えて欲しいです。
SUSとかの仕様でそのあたりの挙動は定義されてましたっけ？
010693
2008/07/22(火) 18:20:41どういうレベルかと言われると良く判らないのですが、
SIGSEGVとか、SIGILLとか、SIGFPEとかのシグナルは、同期シグナルと呼ばれていて、
スレッド側で、signal(3)でハンドラを設定しておいてあげれば、そのシグナルを発生させた
スレッドがシグナルを受け取ってくれるみたいです。
"pthread 同期シグナル" でぐぐった時の２ページ目の最後のマルチスレッドのプログラミング
というSunのPDFへのリンク先の資料に書いてありました。
Solaris10(x86)と、FreeBSD(i386)でサンプルを作ってみたところ、スレッド側で定義した
シグナルハンドラでpthread_self()すると、ちゃんとしたスレッドIDが取得できました。
010793
2008/07/22(火) 18:55:400108105
2008/07/22(火) 20:40:51ありがとうございます。
comp.programming.threads FAQにも、
Q40: Which signals are synchronous, and whicn are are asynchronous?
というのがあって、同じような記述がされてました。
POSIXとかの仕様として挙動がちゃんと決まっているなら、安心してこの性質が使える
と思うのですが、実装依存と言われると便利だけど使いにくいなぁと思ったもので…
0109名無しさん＠お腹いっぱい。
2008/07/23(水) 09:00:47子スレッドは終了時にsemaphoreを解放して、
管理スレッドはsemaphoreを得てスレッド作ればいいだけの話。
シグナルハンドラから安全にpthread_*呼び出せるかどうかは知らんがな。
やろうとも思わん。
0110名無しさん＠お腹いっぱい。
2008/07/24(木) 00:03:24mutex で保護したカウンタを、スレッド数で初期化して作っておいて、
待つ側のスレッドはそのカウンタが0になるまでpthread_cond_wait()、
終了するスレッドは、pthread_exit()する直前にカウンタをデクリメント、
もしカウンタがゼロになったらpthread_cond_signal()すればいいだけ。
かんたん。
pthread_join()は使う必要ない。
あとSIGSEGVが起きているということは、そのプロセス内のメモリ空間は
ぶち壊れて不整合が起きているってことだから、さっさとプロセスごと
死ぬべき。そんな状態で動作を続けたら、誤動作して余計悲惨なことに
なるのがオチ。
0111名無しさん＠お腹いっぱい。
2008/07/24(木) 01:25:25SEGVから戻ってこれるケースもあるわけで、そこまで言いきるのはどうかな。
0112名無しさん＠お腹いっぱい。
2008/07/24(木) 02:29:58>>98は明らかにそういうケースじゃないけどな。
011393
2008/07/24(木) 09:46:56/* 全てのワーカースレッドの終了を待つ */
pthread_mutex_lock(&m_end);
while (0 != thread_num) {
while(NULL == thr_end) {
pthread_cond_wait(&c_end, &m_end);
}
nrc = pthread_join(thr_end, NULL);
if (0 == nrc) {
fprintf(stdout, "thread %5d is exited...\n", thr_end);
--thread_num;
thr_end = NULL;
}else{
fprintf(stdout, "Error pthread_join() return %d\n", nrc);
}
pthread_cond_broadcast(&c_end);
}
pthread_mutex_unlock(&m_end);
fprintf(stdout, "ALL thread is exited... thread_num=%d\n", thread_num);
011493
2008/07/24(木) 09:47:40/* メインスレッドに処理終了を通知 */
pthread_mutex_lock(&m_end);
while (NULL != thr_end) {
pthread_cond_wait(&c_end, &m_end);
}
thr_end = pthread_self();
pthread_cond_broadcast(&c_end);
pthread_mutex_unlock(&m_end);
pthread_exit((void *)NULL);
011593
2008/07/24(木) 09:51:36添削してもらおうとは思ってないけど、とりあえずいろいろ教えてもらったので
張っときます。
複数の子プロセスの任意のタイミングでの終了を親プロセスが待つって
いうケース(親がwaitpid(2)で任意の子プロセスの終了を待つ)を想定してます。
0116名無しさん＠お腹いっぱい。
2008/07/24(木) 10:44:00011793
2008/07/24(木) 11:24:46親(メイン)スレッドがいつ居なくなるか判らない複数の子(ワーカー)スレッドの終了を待っていて
どれかの子(ワーカー)が居なくなったら、それをハンドリング(どの子が居なくなったかを認識)するってどうやるの？
0118名無しさん＠お腹いっぱい。
2008/07/24(木) 11:37:20条件変数は使いまわさず親スレッド起床用と子スレッド起床用とで分けた方がよくね?
0119名無しさん＠お腹いっぱい。
2008/07/24(木) 11:46:43じゃあやっぱcondかな。
0120名無しさん＠お腹いっぱい。
2008/07/24(木) 12:01:12子から親になにか渡さないといけないなら、親側に渡してから死ぬ。
0121名無しさん＠お腹いっぱい。
2008/07/24(木) 12:04:34ハンドリングまでするならqueueだな。
どちらもmutexとcondition variableで書けるのはいいとして、
pthreadでの標準的な実装はないのかな?
012293
2008/07/24(木) 12:52:22最初はそう考えたんですが、親がcond_waitしてないときに子が親にcond_signal
するケースを考えると、なんか余計に複雑になるような気がして、
>>113
>>114
に落ち着いたんです。
条件変数分けると、mutexも分けないといけないし。
(ん？ 条件変数だけ分けてmutexは使い回せばよい？)
もっかい考えてみる。
>>120
ケースバイケースだと思うんだけど、pthreadでプログラム作るときって、detachするのが
どっちかと言うとデフォなの？
>>121
そうなんですよね。
こんなのって定石だと思うんですが、なんでpthread_XXが無いんだろう？
012393
2008/07/24(木) 13:11:48>ハンドリングまでするならqueueだな。
あー、確かに、queue作って、子が死ぬ前に突っ込んで親がそれを拾えば
うまくいきますね。
子が居なくなるのと親がそれを検出するのの同期を取らなくても良い場合は、
それが一番良さそうな気がしますね。
0124名無しさん＠お腹いっぱい。
2008/07/24(木) 13:38:01セマフォは普通にPOSIXのセマフォ使えばいいよね
012593
2008/07/24(木) 13:50:31こんな感じですか。
ワーカー側でcond_broadcast使わなくても良くなったので、無駄なスレッドが
起こされなくなってちょっと軽くなったのかな。
ボス側
pthread_mutex_lock(&m_end);
while (0 != thread_num) {
while(NULL == thr_end) {
pthread_cond_wait(&c_end_boss, &m_end);
}
nrc = pthread_join(thr_end, NULL);
if (0 == nrc) {
fprintf(stdout, "thread %5d is exited...\n", thr_end);
--thread_num;
thr_end = NULL;
}else{
fprintf(stdout, "Error pthread_join() return %d\n", nrc);
}
pthread_cond_broadcast(&c_end_work);
}
pthread_mutex_unlock(&m_end);
ワーカー側
pthread_mutex_lock(&m_end);
while (NULL != thr_end) {
pthread_cond_wait(&c_end_work, &m_end);
}
thr_end = pthread_self();
pthread_cond_signal(&c_end_boss);
pthread_mutex_unlock(&m_end);
pthread_exit((void *)NULL);
012693
2008/07/24(木) 19:31:08同期シグナルは発生要因となったスレッドに送られ、そのスレッド上でシグナルハンドラが起動される。
非同期シグナルは、それを受け取る準備をしているスレッドに送られる。(結果的に、同期的にシグナルを扱うことが出来る)
いずれの場合も、シグナルを受け取ったスレッドでpthread_XXを使ってもうまく動くと思うんですが、間違ってますか？
ようは、SIGSEGVのハンドラからpthread_XXを呼んでみるとうまく動いているように見えるんだけど、
これって、実装(環境)依存なだけなのか、そうでないのかが知りたいんです。
0127名無しさん＠お腹いっぱい。
2008/07/25(金) 02:27:24SIGSEGVが起きる状況の場合、SIGSEGVのきっかけとなったメモリ破壊の結果、
pthread_mutex_tやpthread_cond_tまで巻きぞえをくらって壊れている可能性
がある。その状況でpthread関数を呼んでちゃんと動く保証なんてありえない。
シグナルハンドラから呼ばれて正常動作する保証があるのは、マニュアルに
async-signal-safeと明記されている関数だけ。
そういう関数は、実際のところはシステムコールであることが多い。
012893
2008/07/25(金) 10:14:40私がSIGSEGVを発生させたパターンは単に、NULLアドレスに書き込んでるだけなので、
その辺のデータ(pthread関数が使用している内部データ)を壊してるって訳ではないです。
そもそも、シグナルハンドラからPthread関数が呼べない理由ってのは何故なんでしょう？
Pthread関数の内部データはそのスレッドのスタック上に存在していて、
シグナルハンドラはスレッドとは別のスタックを使って実行されるからって事ですか？
0129名無しさん＠お腹いっぱい。
2008/07/25(金) 11:07:22mutexとかのリソース持ってる状態でシグナル発生したら状態復旧は絶望的だお。
0130名無しさん＠お腹いっぱい。
2008/07/25(金) 11:13:240131名無しさん＠お腹いっぱい。
2008/07/25(金) 11:44:36013293
2008/07/25(金) 12:44:25クライアントからの接続があったら、ワーカーを起動して、そのあとの処理はワーカに任せる。
といった、定番的なネットワークサーバを書く場合に、いわゆるfork()モデルと、スレッドモデルで
どのような差があるのか(特にエラー発生時において)という事です。
なので、ワーカー側の処理ってのは、基本的に独立していてワーカー同士で共有を行うデータも
不要であると考えています。
非同期シグナルも使う必要は無いと考えています。(多分)
fork()モデルの場合は、ワーカプロセスが同期シグナル(SIGSEGV,SIGILL等)を発生させたとしても、
他のワーカープロセスへの影響は特に無く、再度クライアントが接続してくれば、また、サービスを
再開することが出来ます。
スレッドモデルで同じことを実装することは可能なのか？
特定のワーカーが何らかの理由で同期シグナルを発生させた場合、その特定のワーカが死ぬのは
しょうがないと思うんですが、他のワーカーまで道連れにしてしまうのは避けたいと思っています。
スレッドモデルを使ってこのような処理を安全に書けないって事は無いんじゃないのって思うんですが、
いかがなもんでしょう？
また、MySQLはマルチスレッドで動いているらしいのですが、こういったDBサーバは更に複数のワーカ間で
データの排他や同期を取る必要があると思うんですが、こういったプログラムは同期シグナルとどうやって
折り合いをつけているんでしょうか。
これがいわゆる茨の道ってやつですか？
013393
2008/07/25(金) 12:52:01まだ、なにも作ってないですよ。
pthreadというか、マルチスレッドのプログラムを作るのが始めてなので、
いろいろサンプルを作って勉強している最中です。
このスレとっても勉強になります。
レスしてくださっている皆さんありがと。
ところで、本屋行っても、pthread(マルチスレッド)に関する書籍ってほとんどないですよね。
あっても、１０年ぐらい前に出版されたものが殆んどで。
この先、CPUはメニィコアに進もうとしているからもっと沢山あっても良いと思うんですが、
pthreadってあんまり使わないんですかね？
0134名無しさん＠お腹いっぱい。
2008/07/25(金) 12:57:45想定しているのがSIGSEGVやSIGILLのようなプログラムロジックの
バグである限り、不可能というのが答。
プロセスには、スレッドに比べて、メモリ空間が分離されていて
SIGSEGVやSIGILLのような誤動作の影響を完全に排除できるという
特徴がある。つまり、まさにプロセスの利点に当てはまるケースな
わけで、このような想定状況で、スレッドにプロセスと同等の信頼性
を求めることはできない。
> こういったプログラムは同期シグナルとどうやって折り合いをつけて
> いるんでしょうか。
バグが原因で発生するシグナルは別として、sigwait() で対処するのが常識。
013593
2008/07/25(金) 13:40:09そっか。
やっぱりそうなんですか。
非同期シグナルであれば、シグナル受け専のスレッドを立てておいて、そこで
sigwait()するってのは判るんですが、同期シグナルはsigwait()では待てないですもんね？
ん？待てるのか？
ちょっと試してみる。
でも、待てたとしても、どのスレッドがその同期シグナルを発生させたかって、シグナル受け専
スレッドで判らないけりゃどうしようもないですし。
0136名無しさん＠お腹いっぱい。
2008/07/26(土) 12:58:410137名無しさん＠お腹いっぱい。
2008/07/26(土) 17:23:080138名無しさん＠お腹いっぱい。
2008/07/26(土) 19:24:07それ自体がスレッドセーフな作りになってるってわけじゃなかったはず。
013993
2008/07/29(火) 10:32:25ボス側で全てのシグナルをブロックし、シグナル受信専用スレッドを作成し、そこでsigwait()。
ワーカースレッドでSGISEGVを発生させるために、NULLアドレスに書き込み。
結果は、プロセスごと終了。
同期シグナルは発生元のスレッドに送られるのでシグナル受信専用スレッドでsigwait()していても
捕まえる事が出来ないってことですね。
同期シグナルは、ワーカースレッド側でsigset()して、シグナルハンドラ側でボスに >>125 すれば、
とりあえずハンドリングは出来ますが、 >>127 にもあるように、どこまで動くのかは不明ですね。
>>134 にもあるように、この辺りがマルチスレッドと、マルチプロセスの差という事なんですね。
そもそもスレッドってなに？、スタックとスレッドの関係って？、プロセスとスレッドの関係って？
OSはスレッドをどう認識してるの？
なんてことが判っている人にとっては自明なんでしょうが、私にもようやくこの辺りが判って来た
様な気がします。
なかなか使いどころが難しいですが、面白い仕組みですね。
0140名無しさん＠お腹いっぱい。
2008/07/30(水) 21:16:410141名無しさん＠お腹いっぱい。
2008/08/09(土) 19:15:440142名無しさん＠お腹いっぱい。
2008/08/09(土) 20:02:320143名無しさん＠お腹いっぱい。
2008/08/09(土) 20:41:21俺の弟がスレッドの熟練者なのだがおれはいつも勝つから相手が気の毒になったので聞いただけなんだがむかついたので「お前ｼｸﾞﾅﾙでﾎﾞｺるわ・・」と
言ってmain直後に力を溜めてkillしたら多分リアルでビビったんだろうな、、pthread_sigmaskしてたからｻｽﾍﾟﾝﾄﾞしてｶｶッっとforkしながらkillしたらかなり青ざめてた
おれは一気にlongjmpしたんだけどスレッドが硬直してておれの動きを見失ったのか動いてなかったからｺﾏﾝﾄﾞ投下で排他を崩した上についげきのデッドロックでさらにﾀﾞﾒｰｼﾞは加速した。
わざとｾﾏﾌｫをとり「俺はこのままﾀｲﾑｱｳﾄでもいいんだが？」というとようやく必死な顔してなんかｺｰﾄﾞのはしっこからﾌﾞﾛｯｸ型ｼｽﾃﾑｺｰﾙ出してきた。
おれはselectで回避、これは一歩間違えるとｶｳﾝﾀｰで大ﾀﾞﾒｰｼﾞを受ける隠し技なので後ろのギャラリーが拍手し出した。
俺は「うるさい、気が散る。一瞬の油断が命取り」というとｷﾞｬﾗﾘｰは黙った
スレッドは必死にやってくるが、時既に時間切れ、ｽﾀｯｸｶﾞｰﾄﾞを固めた俺にｽｷはなかった
たまに来るｽﾀｯｸｶﾞｰﾄﾞでは防げない攻撃もexitで撃退、終わる頃にはズタズタにされたﾒﾓﾘ空間のcoreがいた
0144名無しさん＠お腹いっぱい。
2008/08/10(日) 03:35:51だがたよりにされたいからMTに分けてもダメだと言う事が最近わかった
MTに分けるのは真にMTの問題だから処理を分けたくて分割するんじゃない
分かれてしまう処理がMT
GUIはざんねんがはっきりいってmutexはつかわないしAPIもMT-unsafeとかイマイチだから信頼されにくい
0145名無しさん＠お腹いっぱい。
2008/08/15(金) 13:04:59プロセスはお前等のためにメモリ空間提供してやってるんだからな
プロセスが終了すればすぐ死ぬくせに調子こき過ぎ
あまり調子に乗ってると裏世界でひっそり幕を閉じる
0146名無しさん＠お腹いっぱい。
2008/10/09(木) 04:28:390147名無しさん＠お腹いっぱい。
2009/11/04(水) 21:43:340148名無しさん＠お腹いっぱい。
2009/11/04(水) 23:49:54http://www.opengroup.org/onlinepubs/000095399/functions/sched_yield.html
0149名無しさん＠お腹いっぱい。
2009/12/07(月) 01:53:370150名無しさん＠お腹いっぱい。
2009/12/08(火) 15:14:40FILE* p = popen("ps aux", "r");
while(fgets(buf,sizeof(buf),p)){
...
}
0151名無しさん＠お腹いっぱい。
2009/12/08(火) 20:09:24それプロセスの一覧じゃね？ だいじょうぶ？
0152名無しさん＠お腹いっぱい。
2009/12/12(土) 02:28:190153名無しさん＠お腹いっぱい。
2009/12/12(土) 12:57:32大抵のpsにはスレッド(LWP)も表示するオプションがある。
>>152
引き継がれるから問題が起きやすい。
ttp://d.hatena.ne.jp/yupo5656/20040715/p1
0154名無しさん＠お腹いっぱい。
2009/12/12(土) 13:24:05* forkして作ったプロセスはsingle threadだよ。
* マルチスレッドプロセスからforkすると、fork呼んだスレッドひとつとmutexの状態とかも含めてプロセス空間が複製されるよ
forkallというスレッド丸ごとforkするのは却下されたってあるね。
0155名無しさん＠お腹いっぱい。
2009/12/12(土) 15:51:24なるほど、forkしてすぐexecなら問題ないけどそれ以外なら死ぬのんか
system関数がNGなのはここでひっかかるんかな
0156名無しさん＠お腹いっぱい。
2009/12/19(土) 16:08:13どうしたらいい？
0157名無しさん＠お腹いっぱい。
2009/12/20(日) 12:42:35ptrace の p は process の p。
SEGV って嫌われてるのな。
昔 mmap(2) した後に mprotect(2) して SEGV 捕捉しながらキャッシュを昇格させる
ような DB 作ったなぁ。
0158名無しさん＠お腹いっぱい。
2009/12/20(日) 18:54:37straceで追うときは、-fか-Fをつければ追えるし。
やっぱstraceを気合い入れて読むしかないのかなぁ・・・嫌だなぁ・・・
0159名無しさん＠お腹いっぱい。
2009/12/20(日) 19:33:17Linuxは、なんかごっちゃにしてるとこあるけど
0160名無しさん＠お腹いっぱい。
2009/12/20(日) 20:33:100161名無しさん＠お腹いっぱい。
2009/12/21(月) 01:47:450162名無しさん＠お腹いっぱい。
2009/12/21(月) 20:29:34メモリがちょいっと共有されてるだけで
0163名無しさん＠お腹いっぱい。
2009/12/22(火) 00:03:45今でも中身は基本的にそれと変わってないね
まあ、誰も困ってないようだから、そういう実装もアリなんだろうけど
0164名無しさん＠お腹いっぱい。
2009/12/22(火) 02:36:56ケースで、FreeBSD だと数千位作れたのに Linux だと
数百でアウトだったのは多分その辺の何かが影響してる
と思う。
0165名無しさん＠お腹いっぱい。
2009/12/22(火) 02:40:11そりゃシステムで上限決めてっからだよ
ulimitコマンドとかでGENKAI TOPPAしる
0166名無しさん＠お腹いっぱい。
2009/12/22(火) 06:03:03だからその辺の上限の根拠が、って話だよ。
0167名無しさん＠お腹いっぱい。
2009/12/22(火) 07:45:20絶対違う。
賭けてもいいぜ。
>>164は32bit環境で、かつ、各スレッドのスタックサイズをデフォルトのままで試してるから。
>>164のような制限として、確かに他の理由もあるが
そんなに少なく制限され、しかもあからさまな差がつく理由なんて一つしかない。
(デフォルトで)スタック10Mの32bitOSで各プロセス最大何スレッド程度作れるか
同じく1MのOSでは各プロセスで計いくつか
ちょっとだけ考えてみな。
0168名無しさん＠お腹いっぱい。
2009/12/22(火) 08:05:110169名無しさん＠お腹いっぱい。
2009/12/22(火) 09:24:511プロセスあたりのスタックサイズを継承すっから
そのデフォルトが由来じゃね？
0170名無しさん＠お腹いっぱい。
2009/12/22(火) 09:52:26起因しているという主張は、プロセス数の上限も数百であるという事と同値。
ところがそんな(数百)プロセス数制限はない。
よって、>>164の主張は間違っている。証明完了。
実験だけで終わらせ、真の原因を突き止めようとしないのはB級エンジニア。
0171名無しさん＠お腹いっぱい。
2009/12/22(火) 10:34:19ただのてーへんだろ？
0172名無しさん＠お腹いっぱい。
2009/12/22(火) 13:13:46> Linux、psで表示しないだけで内部的には完全にプロセスだよね。
いつの時代の話だw
>>164
7,8年前から性能も大逆転だが?
0173名無しさん＠お腹いっぱい。
2009/12/22(火) 13:15:13そっとしておいてやれ。
0174名無しさん＠お腹いっぱい。
2009/12/22(火) 19:23:08＞いつの時代の話だw
違うの？だって隠しプロセスIDを指定してstraceで追うとか出来るよ？
概念的にはともかく実装上はプロセスの延長かと思ってた。
なんか実装上で「ほらここ見ろ」って場所教えてください。
0175名無しさん＠お腹いっぱい。
2009/12/22(火) 21:47:53つ ttp://www.ibm.com/developerworks/jp/linux/library/l-linux-kernel/
プロセス管理は、プロセスの実行に集中的に取り組みます。カーネルではプロセスは
スレッドと呼ばれ、プロセッサーの個々の仮想化 (スレッド・コード、データ、スタック、
および CPU レジスター) を表します。ユーザー空間ではプロセスという用語が一般的に
使用されていますが、Linux 実装ではこの 2 つの概念 (プロセスとスレッド) を
区別していません。カーネルは SCI を介して、新規プロセスの作成 (fork、exec、または
POSIX (Portable Operating System Interface) 関数)、プロセスの停止 (kill、exit)、
そしてプロセス間の通信と同期 (信号、または POSIX メカニズム) を行うための
アプリケーション・プログラム・インターフェース (API) を提供します。
0176名無しさん＠お腹いっぱい。
2009/12/23(水) 00:11:53> ところがそんな(数百)プロセス数制限はない。
メモリ量に依存するけど?
http://www.gelato.unsw.edu.au/lxr/source/kernel/fork.c
> max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
0177B級エンジニア
2009/12/23(水) 00:27:34ここで process と thread に区別はないのはいいよな?
プロセス数とスレッド数の合計は max_threads を越え
られない。また、pthread_attr_setstackaddr() でどう
こうしようがこの制限からは逃れられないので >>167
も的外れ。
これを「プロセス≡スレッドに起因してる」っていうの
は、そんなに言い過ぎかね?
0178名無しさん＠お腹いっぱい。
2009/12/23(水) 03:24:34プロセスとスレッドを統一的に扱っているって感じでしょ。
今は。昔は特殊なプロセスとして実装していたけど。
だからsignalの扱いが変だった。
FreeBSDはrforkとpthreadが別フレームワーク上の実装で
もうちょっと整理できないのかと思う。
0179名無しさん＠お腹いっぱい。
2009/12/23(水) 10:05:31すると（当然こいつも区別無かったんだが）、Linux 実
装の方がお手軽実装（悪く言えば手抜き）に見える。
それに Linux 側も最近はスレッド≡プロセスの柵から
脱却しつつあるんじゃなかったっけ?
0180名無しさん＠お腹いっぱい。
2009/12/23(水) 11:33:400181名無しさん＠お腹いっぱい。
2009/12/23(水) 13:06:48Solaris8までは、M:Nだったと言うことはスレッド≡プロセスではないよね。
0182名無しさん＠お腹いっぱい。
2009/12/23(水) 15:02:53
■ このスレッドは過去ログ倉庫に格納されています