[#20525] [BigDecimal] changing rule of coerce — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>

斎藤です。

44 messages 2003/07/07
[#20527] Re: [BigDecimal] changing rule of coerce — "Shigeo Kobayashi" <shigeo@...> 2003/07/07

小林です。

[#20528] Re: [BigDecimal] changing rule of coerce — matz@... (Yukihiro Matsumoto) 2003/07/07

まつもと ゆきひろです

[#20570] Marshal upgrade — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

41 messages 2003/07/09
[#20575] Re: Marshal upgrade — Masatoshi SEKI <m_seki@...> 2003/07/09

咳といいます。

[#20583] Re: Marshal upgrade — matz@... (Yukihiro Matsumoto) 2003/07/09

まつもと ゆきひろです

[#21016] Re: Marshal upgrade — matz@... (Yukihiro Matsumoto) 2003/07/30

まつもと ゆきひろです

[#20804] add library — nobu.nakada@... 2003/07/23

なかだです。

[#20580] add library(Re:ruby-dev:20570) — たむらけんいち <sgs02516@...>

たむらです。

30 messages 2003/07/09
[#20656] Re: add library — "NAKAMURA, Hiroshi" <nakahiro@...> 2003/07/14

なひです。

[#20658] Re: add library — GOTOU Yuuzou <gotoyuzo@...> 2003/07/14

In message <038d01c349cb$eaad71d0$93222fc0@sarion.co.jp>,

[#20659] Re: add library — matz@... (Yukihiro Matsumoto) 2003/07/14

まつもと ゆきひろです

[#20660] Re: add library — GOTOU Yuuzou <gotoyuzo@...> 2003/07/14

In message <1058171960.400840.10041.nullmailer@picachu.netlab.jp>,

[#20661] Re: add library — Takahiro Kambe <taca@...> 2003/07/14

話をそらしてしまうかもしれませんが、

[#20665] Re: add library — GOTOU Yuuzou <gotoyuzo@...> 2003/07/14

In message <20030714.183104.09092354.taca@back-street.net>,

[#20666] Re: add library — Takahiro Kambe <taca@...> 2003/07/14

In message <20030715.013655.424936247.gotoyuzo@kotetsu.does.notwork.org>

[#20668] Re: add library — GOTOU Yuuzou <gotoyuzo@...> 2003/07/14

In message <20030715.025907.26217115.taca@back-street.net>,

[#20750] Re: add library — Takahiro Kambe <taca@...> 2003/07/21

In message <20030715.051853.968499478.gotoyuzo@kotetsu.does.notwork.org>

[#20751] Re: add library — GOTOU Yuuzou <gotoyuzo@...> 2003/07/21

In message <20030721.163444.09092937.taca@back-street.net>,

[#20655] frozen ThreadGroup — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

26 messages 2003/07/14
[#20671] Re: frozen ThreadGroup — matz@... (Yukihiro Matsumoto) 2003/07/14

まつもと ゆきひろです

[#20673] Re: frozen ThreadGroup — Hidetoshi NAGAI <nagai@...> 2003/07/15

永井@知能.九工大です.

[#20676] Re: frozen ThreadGroup — matz@... (Yukihiro Matsumoto) 2003/07/15

まつもと ゆきひろです

[#20677] Re: frozen ThreadGroup — Hidetoshi NAGAI <nagai@...> 2003/07/15

永井@知能.九工大です.

[#20681] Re: frozen ThreadGroup — matz@... (Yukihiro Matsumoto) 2003/07/15

まつもと ゆきひろです

[#20690] portable(?) UserID/GroupID control (Re: frozen ThreadGroup) — Hidetoshi NAGAI <nagai@...> 2003/07/16

永井@知能.九工大です.

[#20712] Re: portable(?) UserID/GroupID control — Hidetoshi NAGAI <nagai@...> 2003/07/17

永井@知能.九工大です.

[#20735] Re: portable(?) UserID/GroupID control — matz@... (Yukihiro Matsumoto) 2003/07/20

まつもと ゆきひろです

[#20736] Re: portable(?) UserID/GroupID control — Hidetoshi NAGAI <nagai@...> 2003/07/20

永井@知能.九工大です.

[#20737] Re: portable(?) UserID/GroupID control — matz@... (Yukihiro Matsumoto) 2003/07/20

まつもと ゆきひろです

[#20748] [BigDecimal] exception handling — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>

斎藤です。

20 messages 2003/07/21

[#20765] Re: [ruby-cvs] ruby/lib: * lib/tmpdir.rb: new library to get temporary directory path, — WATANABE Hirofumi <eban@...>

わたなべです。

9 messages 2003/07/21

[#20780] complex.rb — Masahiro TANAKA <masa@...>

complex.rb についての修正案を[ruby-math:00543]で提案しましたが、その後

25 messages 2003/07/22
[#20782] Re: complex.rb — matz@... (Yukihiro Matsumoto) 2003/07/22

まつもと ゆきひろです

[#20900] Re: complex.rb — Masahiro TANAKA <masa@...> 2003/07/25

At Tue, 22 Jul 2003 17:30:31 +0900, Yukihiro Matsumoto wrote:

[#20905] Re: complex.rb — matz@... (Yukihiro Matsumoto) 2003/07/25

まつもと ゆきひろです

[#20906] Re: complex.rb — keiju@... (石塚圭樹) 2003/07/25

けいじゅ@いしつかです.

[#20810] Rational 始めました。 — Shin-ichiro HARA <sinara@...>

原です。

13 messages 2003/07/23
[#20876] Re: Rational 始めました。 — keiju@... (石塚圭樹) 2003/07/24

けいじゅ@いしつかです.

[#20954] ruby 1.8.0 preview5 — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

15 messages 2003/07/28

[#20957] [BigDecimal] conflict between Numeric#div and BigDecimal#div — "Tadashi Saito" <shiba@...2.accsnet.ne.jp>

斎藤です。

29 messages 2003/07/28
[#20960] Re: [BigDecimal] conflict between Numeric#div and BigDecimal#div — Masahiro TANAKA <masa@...> 2003/07/28

At Mon, 28 Jul 2003 18:26:20 +0900, Tadashi Saito wrote:

[#20962] Re: [BigDecimal] conflict between Numeric#div and BigDecimal#div — matz@... (Yukihiro Matsumoto) 2003/07/28

まつもと ゆきひろです

[#20990] Re: [BigDecimal] conflict between Numeric#div and BigDecimal#div — Masahiro TANAKA <masa@...> 2003/07/29

At Mon, 28 Jul 2003 21:16:08 +0900, Yukihiro Matsumoto wrote:

[#20992] Re: [BigDecimal] conflict between Numeric#div and BigDecimal#div — matz@... (Yukihiro Matsumoto) 2003/07/29

まつもと ゆきひろです

[ruby-dev:20673] Re: frozen ThreadGroup

From: Hidetoshi NAGAI <nagai@...>
Date: 2003-07-15 03:00:38 UTC
List: ruby-dev #20673
永井@知能.九工大です.

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));
 }

In This Thread