[#20490] [BUG] evalがらみでSIGSEGV — "yamamoto madoka" <dan@...2.so-net.ne.jp>
こんにちは、山本 円と申します。
[#20495] 不正なバイト列とのマッチ — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#20499] Re: [ruby-cvs] ruby/ext/curses: * string.c (rb_str_shared_replace): clear flags before copy. — nobu.nakada@...
なかだです。
まつもと ゆきひろです
わたなべです。
まつもと ゆきひろです
わたなべです。
[#20525] [BigDecimal] changing rule of coerce — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>
斎藤です。
小林です。
まつもと ゆきひろです
小林です。
小林です。
前田です。
小林です。
小林です。
小林です。
小林です。
小林です。
[#20570] Marshal upgrade — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
咳といいます。
まつもと ゆきひろです
まつもと ゆきひろです
新井です。
新井です。
まつもと ゆきひろです
咳といいます。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
[#20580] add library(Re:ruby-dev:20570) — たむらけんいち <sgs02516@...>
たむらです。
なひです。
In message <038d01c349cb$eaad71d0$93222fc0@sarion.co.jp>,
まつもと ゆきひろです
In message <1058171960.400840.10041.nullmailer@picachu.netlab.jp>,
話をそらしてしまうかもしれませんが、
In message <20030714.183104.09092354.taca@back-street.net>,
In message <20030715.013655.424936247.gotoyuzo@kotetsu.does.notwork.org>
In message <20030715.025907.26217115.taca@back-street.net>,
In message <20030715.051853.968499478.gotoyuzo@kotetsu.does.notwork.org>
In message <20030721.163444.09092937.taca@back-street.net>,
In message <20030721.191306.60866533.gotoyuzo@kotetsu.does.notwork.org>
In message <20030721.211845.20473808.taca@back-street.net>,
In message <20030722.002037.774147317.gotoyuzo@kotetsu.does.notwork.org>
In message <20030722.003236.72433302.taca@back-street.net>,
[#20582] rexmlのuconv依存 — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
まつもと ゆきひろです
In article <1057770842.878440.16422.nullmailer@picachu.netlab.jp>,
なかだです。
In article <200307100751.h6A7pLFs003667@sharui.nakada.kanuma.tochigi.jp>,
[#20606] ruby-1.8.0 on BSD/OS — OHARA Shigeki <os@...>
大原です。
[#20613] compiling Ruby on AIX (powerpc-ibm-aix4.3.3.0) and Alpha OSF/1 (alphaev67-dec-osf5.1) — NISHIMATSU Takeshi <t-nissie@...>
西松と申します.
なかだです。
西松です. お返事が遅くなり申し訳ありません.
[#20631] SOAP4R in 1.8.0? — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#20655] frozen ThreadGroup — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
In article <1058719939.886480.22830.nullmailer@picachu.netlab.jp>,
[#20680] 1.8.0 on IA64 etc. — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#20691] Re: [Oniguruma] explicit capture — kkosako@...
> -----Original Message-----
[#20716] Re: [Oniguruma] explicit capture — kkosako@...
> -----Original Message-----
[#20748] [BigDecimal] exception handling — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>
斎藤です。
[#20765] Re: [ruby-cvs] ruby/lib: * lib/tmpdir.rb: new library to get temporary directory path, — WATANABE Hirofumi <eban@...>
わたなべです。
まつもと ゆきひろです
わたなべです。
まつもと ゆきひろです
わたなべです。
[#20780] complex.rb — Masahiro TANAKA <masa@...>
complex.rb についての修正案を[ruby-math:00543]で提案しましたが、その後
まつもと ゆきひろです
けいじゅ@いしつかです.
At Tue, 22 Jul 2003 17:30:31 +0900, Yukihiro Matsumoto wrote:
まつもと ゆきひろです
けいじゅ@いしつかです.
At Sat, 26 Jul 2003 06:52:21 +0900, 石塚圭樹 wrote:
[#20791] 1.8.0 preview4 schedule — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
永井@知能.九工大です.
[#20795] warning: terminated thread — Masatoshi SEKI <m_seki@...>
咳といいます。
mput です。こんばんわ。
まつもと ゆきひろです
[#20800] 0**(-1) with rational — Tanaka Akira <akr@...17n.org>
そういえば思い出したのですが、rational を require しているときとしてい
At Wed, 23 Jul 2003 03:30:41 +0900, Tanaka Akira wrote:
[#20810] Rational 始めました。 — Shin-ichiro HARA <sinara@...>
原です。
けいじゅ@いしつかです.
In article <200307241940.EAA14225.keiju@ishitsuka.com>,
けいじゅ@いしつかです.
In article <200307271500.AAA04363.keiju@bc.mbn.or.jp>,
[#20818] ThreadGroup#wait — nobu.nakada@...
なかだです。
まつもと ゆきひろです
[#20868] ruby 1.8.0 preview4 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#20887] ext/openssl undefined BN_pseudo_rand_range — Kazuhiro Yoshida <moriq@...>
もりきゅうです。
[#20915] [BUG] errno == 0 — Kazuhiro Yoshida <moriq@...>
もりきゅうです。win32だけかもしれません。
まつもと ゆきひろです
もりきゅうです。
[#20932] move ChangeLog — Tanaka Akira <akr@...17n.org>
提案なんですが、1.8.0 が出たらそこまでのぶんの ChangeLog を移動しませ
[#20949] multiple Tk interpreter support — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#20954] ruby 1.8.0 preview5 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
もりきゅうです。
Siena. です。
[#20957] [BigDecimal] conflict between Numeric#div and BigDecimal#div — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>
斎藤です。
At Mon, 28 Jul 2003 18:26:20 +0900, Tadashi Saito wrote:
まつもと ゆきひろです
At Mon, 28 Jul 2003 21:16:08 +0900, Yukihiro Matsumoto wrote:
まつもと ゆきひろです
At Tue, 29 Jul 2003 14:43:19 +0900, Yukihiro Matsumoto wrote:
原です。
[#20989] Re: [Oniguruma] explicit capture — kkosako@...
> -----Original Message-----
[#21027] -W option — WATANABE Hirofumi <eban@...>
わたなべです。
[ruby-dev:20673] Re: frozen ThreadGroup
永井@知能.九工大です.
From: matz@ruby-lang.org (Yukihiro Matsumoto)
Subject: [ruby-dev:20671] Re: frozen ThreadGroup
Date: Tue, 15 Jul 2003 08:28:05 +0900
Message-ID: <1058225311.060472.28862.nullmailer@picachu.netlab.jp>
> 論点は分かります。ただ、freezeというのは「変化しない」ことを
> 意味しますから、
>
> |freeze された ThreadGroup に新たな Thread が追加されるのは,
> |freeze 前からその ThreadGroup に含まれていた Thread が
> |新たな Thread を生成した場合のみです.
>
> というように条件によってfreezeされているのに新たなthreadが追
> 加されるというのはなじまないかもしれません。
そうですねぇ...
「ThreadGroup::Default をいきなり freeze させてしまったら」
といったケースも考えて,同一スレッドグループ内での
サブスレッド生成までは許容せざるを得ないだろうと思っていました.
しかし,確かに「ThreadGroup オブジェクトの内部状態が変化してしまう」
ということ自体が freeze となじまないと感じることはわかります.
# ただ,ThreadGroup オブジェクトを freeze しても
# スレッド追加自由という現状は,さらになじんでいないとは思います.
考えてみると,ThreadGroup の freeze(?) 関連の状態には
次の三つが設定できます.
(1) ThreadGroup オブジェクトへの特異メソッド追加等の修正を許さない
(2) ThreadGroup オブジェクトから/へのスレッド追加/削除を許さない
(3) ThreadGroup オブジェクトの登録スレッド変更を許さない
現状の freeze は (1),前回の patch は (1) + (2) で,
本来の意味での freeze は (1) + (3) です.
(3) は厳しすぎと思ってましたが,新規スレッドの生成禁止と考えれば
需要はあるのかもしれません.
とはいえ,全く制約なしか (1) + (3) かの二択というのは
落差が大きすぎのようです.
「では」というわけで,
(1) + (2) ===> enclose / enclosed?
(1) + (3) ===> freeze / frozen?
というのはいかがでしょうか.
現在考えている方法での safeTk の実装上は,
enclose / enclosed? が可能なら十分です.
# frozen? == true の際の enclosed? は true か false かという
# 問題もありますが,私は true で良いと思います.
とりあえず,この案での patch をメール末尾に添えておきます.
ただ,この patch だと enclose された ThreadGroup オブジェクトを
変更しようとすると,can't modify frozen object になってしまいますが,
^^^^^^
これは見なかったことにしています.(^_^;
> その場合でもThreadGroupに新たな属性を追加してこの機能を実現
> することは可能だと思います。また、SafeTkを実現するための別の
> 方法の受け皿を別に思いつく人がいれば、それを取り入れることに
> も反対しません。
こんなことをやりながらも,実は誰かがもっといいアイディアを
出してくれるのを待っています.
# こんな風にもがいてたら,誰か助け船を出してくれないかなぁと.(^_^)
--
永井 秀利 (九工大 知能情報)
nagai@ai.kyutech.ac.jp
Index: eval.c
===================================================================
RCS file: /src/ruby/eval.c,v
retrieving revision 1.479
diff -u -r1.479 eval.c
--- eval.c 11 Jul 2003 19:23:13 -0000 1.479
+++ eval.c 15 Jul 2003 02:56:25 -0000
@@ -7856,6 +7856,8 @@
int abort;
int priority;
int gid;
+ int g_enclosed;
+ int g_frozen;
st_table *locals;
@@ -9188,6 +9190,8 @@
th->abort = 0;\
th->priority = 0;\
th->gid = 1;\
+ th->g_enclosed = 0;\
+ th->g_frozen = 0;\
th->locals = 0;\
} while (0)
@@ -9267,6 +9271,11 @@
enum thread_status status;
int state;
+ if (curr_thread->g_frozen) {
+ rb_raise(rb_eThreadError,
+ "can't start a new thread (frozen ThreadGroup)");
+ }
+
#if defined(HAVE_SETITIMER)
if (!thread_init) {
#ifdef POSIX_SIGNAL
@@ -9301,6 +9310,8 @@
curr_thread->next = th;
th->priority = curr_thread->priority;
th->gid = curr_thread->gid;
+ th->g_enclosed = curr_thread->g_enclosed;
+ th->g_frozen = curr_thread->g_frozen;
}
PUSH_TAG(PROT_THREAD);
@@ -9850,6 +9861,7 @@
struct thgroup {
int gid;
+ int frozen;
};
static VALUE thgroup_s_alloc _((VALUE));
@@ -9863,6 +9875,7 @@
group = Data_Make_Struct(klass, struct thgroup, 0, free, data);
data->gid = serial++;
+ data->frozen = 0;
return group;
}
@@ -9888,6 +9901,69 @@
return ary;
}
+
+VALUE
+thgroup_enclose(group, freeze)
+ VALUE group;
+ int freeze;
+{
+ struct thgroup *data;
+ rb_thread_t th;
+
+ rb_obj_freeze(group);
+
+ Data_Get_Struct(group, struct thgroup, data);
+ if (freeze) {
+ data->frozen = freeze;
+ }
+
+ FOREACH_THREAD(th) {
+ if (th->gid == data->gid) {
+ th->g_enclosed = 1;
+ if (freeze && !th->g_frozen) {
+ th->g_frozen = freeze;
+ }
+ }
+ }
+ END_FOREACH(th);
+
+ return group;
+}
+
+VALUE
+rb_thgroup_enclose(group)
+ VALUE group;
+{
+ return thgroup_enclose(group, 0);
+}
+
+VALUE
+rb_thgroup_freeze(group)
+ VALUE group;
+{
+ return thgroup_enclose(group, 1);
+}
+
+static VALUE
+thgroup_enclosed_p(group)
+ VALUE group;
+{
+ if (OBJ_FROZEN(group)) return Qtrue;
+ return Qfalse;
+}
+
+static VALUE
+thgroup_frozen_p(group)
+ VALUE group;
+{
+ struct thgroup *data;
+
+ if (!OBJ_FROZEN(group)) return Qfalse;
+ Data_Get_Struct(group, struct thgroup, data);
+ if (data->frozen) return Qtrue;
+ return Qfalse;
+}
+
static VALUE
thgroup_add(group, thread)
VALUE group, thread;
@@ -9897,7 +9973,19 @@
rb_secure(4);
th = rb_thread_check(thread);
+
+ if (th->g_enclosed) {
+ rb_raise(rb_eThreadError,
+ "can't move from the %s thread group",
+ th->g_frozen ? "frozen": "enclosed");
+ }
Data_Get_Struct(group, struct thgroup, data);
+ if (data->frozen) {
+ rb_raise(rb_eThreadError, "can't move to the frozen thread group");
+ }
+ if (OBJ_FROZEN(group)) {
+ rb_raise(rb_eThreadError, "can't move to the enclosed thread group");
+ }
th->gid = data->gid;
return group;
@@ -9970,6 +10058,10 @@
cThGroup = rb_define_class("ThreadGroup", rb_cObject);
rb_define_alloc_func(cThGroup, thgroup_s_alloc);
rb_define_method(cThGroup, "list", thgroup_list, 0);
+ rb_define_method(cThGroup, "enclose", rb_thgroup_enclose, 0);
+ rb_define_method(cThGroup, "freeze", rb_thgroup_freeze, 0);
+ rb_define_method(cThGroup, "enclosed?", thgroup_enclosed_p, 0);
+ rb_define_method(cThGroup, "frozen?", thgroup_frozen_p, 0);
rb_define_method(cThGroup, "add", thgroup_add, 1);
rb_define_const(cThGroup, "Default", rb_obj_alloc(cThGroup));
}