[#19731] use of require thread safety — "Roger Pack" <rogerpack2005@...>

I'm sure this has been discussed before, but...should there be

56 messages 2008/11/08
[#19796] Re: use of require thread safety — Nobuyoshi Nakada <nobu@...> 2008/11/11

Hi,

[#21651] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2009/01/29

Nobuyoshi Nakada wrote:

[#19798] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/11/11

> While a thread is requiring a given file, another thread which

[#20732] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/12/20

> Currently with 1.8.7 (for me) the secondmost thread continues

[#20737] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/20

Roger Pack wrote:

[#20769] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/21

Charles Oliver Nutter wrote:

[#20795] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/12/22

On Mon, Dec 22, 2008 at 03:05:07AM +0900, Charles Oliver Nutter wrote:

[#19821] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/11/11

On Tue, Nov 11, 2008 at 10:51:45AM +0900, Nobuyoshi Nakada wrote:

[#19829] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Paul Brannan wrote:

[#19759] Proposal: Method#get_args — "Yehuda Katz" <wycats@...>

I'd like to propose a way to introspect into the arguments of a method

97 messages 2008/11/09
[#19787] Re: Proposal: Method#get_args — "Roger Pack" <rogerpack2005@...> 2008/11/11

The only question I have is why would one want to know the names of

[#19789] Re: Proposal: Method#get_args — Trans <transfire@...> 2008/11/11

On Nov 10, 7:18=A0pm, "Roger Pack" <rogerpack2...@gmail.com> wrote:

[#19818] Re: Proposal: Method#get_args — Mikael Hlund <mikael@...> 2008/11/11

Allow me to throw in my ~.116892074 DKK;

[#19837] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Mikael H淡ilund wrote:

[#19838] Re: Proposal: Method#get_args — Dave Thomas <dave@...> 2008/11/11

[#19870] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Wed, Nov 12, 2008 at 04:48:03AM +0900, Dave Thomas wrote:

[#19874] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Wed, Nov 12, 2008 at 06:01:40PM +0900, Brian Candler wrote:

[#19881] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19887] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Thu, Nov 13, 2008 at 02:06:15AM +0900, Charles Oliver Nutter wrote:

[#19889] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19892] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19893] Re: Proposal: Method#get_args — Jim Deville <jdeville@...> 2008/11/12

> -----Original Message-----

[#19894] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Thu, Nov 13, 2008 at 04:33:07AM +0900, Jim Deville wrote:

[#19895] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19896] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Jim Weirich wrote:

[#19899] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

On Nov 12, 2008, at 4:12 PM, Charles Oliver Nutter wrote:

[#19915] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/13

On Thu, Nov 13, 2008 at 07:02:25AM +0900, Jim Weirich wrote:

[#19927] Re: {Proc,Method}#parameters (Re: Proposal: Method#get_args) — Nobuyoshi Nakada <nobu@...> 2008/11/14

Hi,

[#19784] Status of copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

22 messages 2008/11/10
[#19799] Re: Status of copy-on-write friendly garbage collector — "Narihiro Nakamura" <authornari@...> 2008/11/11

Hi.

[#19812] Re: Status of copy-on-write friendly garbage collector — "Yehuda Katz" <wycats@...> 2008/11/11

Narihiro,

[#19823] Re: Status of copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/11/11

Hi,

[#19845] [Bug #743] Socket.gethostbyname returns odd values — Roger Pack <redmine@...>

Bug #743: Socket.gethostbyname returns odd values

11 messages 2008/11/11

[#19846] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...>

Bug #744: memory leak in callcc?

142 messages 2008/11/11
[#21394] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2009/01/17

Issue #744 has been updated by Roger Pack.

[#21429] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/19

[#21441] Re: [Bug #744] memory leak in callcc? — Nobuyoshi Nakada <nobu@...> 2009/01/19

Hi,

[#21483] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/21

[#21487] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/01/21

On Wednesday 21 of January 2009 10:21:19 Brent Roman wrote:

[#21711] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/02/01

[#22062] Re: [Bug #744] memory leak in callcc? — Roger Pack <rogerdpack@...> 2009/02/14

>> I've tried that myself but it didn't work very well

[#22265] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/02/19

On Saturday 14 of February 2009 08:17:22 Roger Pack wrote:

[#21514] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/22

[#19945] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2008/11/15

Issue #744 has been updated by Roger Pack.

[#19968] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19969] Re: [Bug #744] memory leak in callcc? — Martin Duerst <duerst@...> 2008/11/17

At 12:54 08/11/17, Brent Roman wrote:

[#19970] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19972] Re: [Bug #744] memory leak in callcc? — Kurt Stephens <kurt@...> 2008/11/17

A common technique is to allocate a reasonably sized array (256-bytes)

[#20149] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/28

[#20517] Re: Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/13

> I implemented a scheme for recording the maximum depth of the C stack in

[#20534] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/13

[#20750] [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20751] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Ezra Zygmuntowicz <ezmobius@...> 2008/12/21

[#20752] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20781] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/22

First thanks for doing all that hard work. I'm sure it's not pleasant

[#20783] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/22

[#20903] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/26

Seems to overall be a tidge slower for "micro" stuff--5 or 10%.

[#20914] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/27

[#20922] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/27

> You ran this benchmark suite, correct?

[#20931] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/28

[#20995] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/30

Hmm interesting.

[#21261] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Stephen Sykes" <sdsykes@...> 2009/01/11

Brent,

[#20168] Re: Promising C coding techniques to reduce MRI's memory use — Nobuyoshi Nakada <nobu@...> 2008/11/30

Hi,

[#20175] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/11/30

The problem can be demonstrated with a very simple program (attached), and

[#20178] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/30

[#20185] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/12/01

> What I did come up with was not ugly at all. Factor the unwieldy switch

[#19938] Fibers in 1.8 — "Aman Gupta" <rubytalk@...1.net>

Are there any plans to backport Fiber to ruby 1.8?

13 messages 2008/11/15

[#20008] [Bug #766] 'Not enough space' error on windows — Ittay Dror <redmine@...>

Bug #766: 'Not enough space' error on windows

17 messages 2008/11/20

[#20092] [Bug #797] bug or feature: local method ? — Francois Proulx <redmine@...>

Bug #797: bug or feature: local method ?

23 messages 2008/11/25
[#20097] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20098] Re: [Bug #797] bug or feature: local method ? — Dave Thomas <dave@...> 2008/11/25

[#20100] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20127] Re: [Bug #797] bug or feature: local method ? — Francoys <francois.pr@...> 2008/11/26

Yukihiro Matsumoto wrote:

[ruby-core:19686] Re: [Bug #703] string output duplication occurs if the same file descriptor written to in different threads

From: Nobuyoshi Nakada <nobu@...>
Date: 2008-11-03 17:44:32 UTC
List: ruby-core #19686
Hi,

At Mon, 3 Nov 2008 09:44:44 +0900,
Nobuyoshi Nakada wrote in [ruby-core:19678]:
> > It doesn't happen on either trunk nor 1.8.7.  What's your version, and
> > platform?
> 
> It could reproduced with full ruby, but not with miniruby nor
> full ruby with disabling gems.

It seems a mere timing and probability issue.  And seems solved
by serializing write operations, as Roger figured out.


Index: gc.c
===================================================================
--- gc.c	(revision 20101)
+++ gc.c	(working copy)
@@ -1509,4 +1509,5 @@ gc_mark_children(rb_objspace_t *objspace
             gc_mark(objspace, obj->as.file.fptr->writeconv_pre_ecopts, lev);
             gc_mark(objspace, obj->as.file.fptr->encs.ecopts, lev);
+            gc_mark(objspace, obj->as.file.fptr->write_lock, lev);
         }
         break;
Index: io.c
===================================================================
--- io.c	(revision 20101)
+++ io.c	(working copy)
@@ -525,9 +525,27 @@ rb_write_internal(int fd, void *buf, siz
 }
 
+static long
+io_writable_length(rb_io_t *fptr, long l)
+{
+    if (PIPE_BUF < l &&
+        !rb_thread_alone() &&
+        wsplit_p(fptr)) {
+        l = PIPE_BUF;
+    }
+    return l;
+}
+
+static VALUE
+io_flush_buffer(VALUE arg)
+{
+    rb_io_t *fptr = (rb_io_t *)arg;
+    long l = io_writable_length(fptr, fptr->wbuf_len);
+    return rb_write_internal(fptr->fd, fptr->wbuf+fptr->wbuf_off, l);
+}
+
 static int
 io_fflush(rb_io_t *fptr)
 {
-    int r, l;
-    int wbuf_off, wbuf_len;
+    long r;
 
     rb_io_check_closed(fptr);
@@ -540,13 +558,5 @@ io_fflush(rb_io_t *fptr)
     if (fptr->wbuf_len == 0)
         return 0;
-    wbuf_off = fptr->wbuf_off;
-    wbuf_len = fptr->wbuf_len;
-    l = wbuf_len;
-    if (PIPE_BUF < l &&
-        !rb_thread_alone() &&
-        wsplit_p(fptr)) {
-        l = PIPE_BUF;
-    }
-    r = rb_write_internal(fptr->fd, fptr->wbuf+wbuf_off, l);
+    r = rb_mutex_synchronize(fptr->write_lock, io_flush_buffer, (VALUE)fptr);
     /* xxx: Other threads may modify wbuf.
      * A lock is required, definitely. */
@@ -732,9 +742,23 @@ make_writeconv(rb_io_t *fptr)
 
 /* writing functions */
+struct binwrite_arg {
+    rb_io_t *fptr;
+    VALUE str;
+    long offset;
+    long length;
+};
+
+static VALUE
+io_binwrite_string(VALUE arg)
+{
+    struct binwrite_arg *p = (struct binwrite_arg *)arg;
+    long l = io_writable_length(p->fptr, p->length);
+    return rb_write_internal(p->fptr->fd, RSTRING_PTR(p->str)+p->offset, l);
+}
 
 static long
 io_binwrite(VALUE str, rb_io_t *fptr, int nosync)
 {
-    long len, n, r, l, offset = 0;
+    long len, n, r, offset = 0;
 
     len = RSTRING_LEN(str);
@@ -745,7 +769,10 @@ io_binwrite(VALUE str, rb_io_t *fptr, in
         fptr->wbuf_capa = 8192;
         fptr->wbuf = ALLOC_N(char, fptr->wbuf_capa);
+	fptr->write_lock = rb_mutex_new();
     }
     if ((!nosync && (fptr->mode & (FMODE_SYNC|FMODE_TTY))) ||
         (fptr->wbuf && fptr->wbuf_capa <= fptr->wbuf_len + len)) {
+	struct binwrite_arg arg;
+
         /* xxx: use writev to avoid double write if available */
         if (fptr->wbuf_len && fptr->wbuf_len+len <= fptr->wbuf_capa) {
@@ -767,12 +794,10 @@ io_binwrite(VALUE str, rb_io_t *fptr, in
 	    rb_io_check_closed(fptr);
 	}
+	arg.fptr = fptr;
+	arg.str = str;
+	arg.offset = offset;
       retry:
-        l = n;
-        if (PIPE_BUF < l &&
-            !rb_thread_alone() &&
-            wsplit_p(fptr)) {
-            l = PIPE_BUF;
-        }
-	r = rb_write_internal(fptr->fd, RSTRING_PTR(str)+offset, l);
+	arg.length = n;
+	r = rb_mutex_synchronize(fptr->write_lock, io_binwrite_string, (VALUE)&arg);
 	/* xxx: other threads may modify given string. */
         if (r == n) return len;
@@ -3040,4 +3065,17 @@ finish_writeconv(rb_io_t *fptr, int nora
 }
 
+struct finish_writeconv_arg {
+    rb_io_t *fptr;
+    int noraise;
+};
+
+static VALUE
+finish_writeconv_sync(VALUE arg)
+{
+    struct finish_writeconv_arg *p = (struct finish_writeconv_arg *)arg;
+    finish_writeconv(p->fptr, p->noraise);
+    return Qnil;
+}
+
 static void
 fptr_finalize(rb_io_t *fptr, int noraise)
@@ -3045,5 +3083,13 @@ fptr_finalize(rb_io_t *fptr, int noraise
     int ebadf = 0;
     if (fptr->writeconv) {
-        finish_writeconv(fptr, noraise);
+	if (fptr->write_lock) {
+	    struct finish_writeconv_arg arg;
+	    arg.fptr = fptr;
+	    arg.noraise = noraise;
+	    rb_mutex_synchronize(fptr->write_lock, finish_writeconv_sync, (VALUE)&arg);
+	}
+	else {
+	    finish_writeconv(fptr, noraise);
+	}
     }
     if (fptr->wbuf_len) {
Index: include/ruby/io.h
===================================================================
--- include/ruby/io.h	(revision 20101)
+++ include/ruby/io.h	(working copy)
@@ -74,4 +74,5 @@ typedef struct rb_io_t {
     int writeconv_initialized;
 
+    VALUE write_lock;
 } rb_io_t;
 
@@ -134,4 +135,5 @@ typedef struct rb_io_t {
     fp->encs.ecflags = 0;\
     fp->encs.ecopts = Qnil;\
+    fp->write_lock = 0;\
 } while (0)
 


-- 
Nobu Nakada

In This Thread