[#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:19763] [Bug #738] Repeated calls to popen cause thread problems

From: Michal Suchanek <redmine@...>
Date: 2008-11-10 01:07:27 UTC
List: ruby-core #19763
Bug #738: Repeated calls to popen cause thread problems
http://redmine.ruby-lang.org/issues/show/738

Author: Michal Suchanek
Status: Open, Priority: Normal

This is a repost of an older issue form the other issue tracker.

I am trying to interface a legacy program in my code. This program reads text from stdin and writes them to stdout with some additional information added. Unfortunately it also caches a bit of the output so I cannot just write a piece of text and read it back, I have to 

a) write the results into a temporary file and get them from there

b) use threads in Ruby

Also I have to execute a new instance of the program each time because the cache is only flushed completely when the program exits.

However, (b) is completely out of question because there are various bugs in various Ruby implementation regarding threading and popen.

There are two ways of handling the threading - either have the main thread read the results or have the main thread write the text into the pipe.

Although these should be theoretically equivalent the number of invocations before the interpreter locks up may vary wildly depending on the way roles are assigned to the two threads.

Also there is a problem with the pipe one gets from popen. Using the same IO in both threads is the only safe way in MRI (although caution would advise to duplicate the IO as shown in testt.rb). Duplicating the IO results in deadlock error within about 200 calls in any recent MRI Ruby I tried but is required in JRuby.

The swapping of thread roles had no noticeable affect in MRI Ruries up to some 1.8.5 version but lately only the way shown in testt2.rb works. Although I cannot reproduce any lockup with the testt.rb if I remove the IO duplication running my application this way results in occasional intermittent thread deadlock messages that can be worked around by repeatedly processing the same data until the whole task finishes.

Note that in JRuby the required approach is exactly the opposite to what is required in MRI. The IO has to be duplicated for JRuby and the threads have to be swapped. This lack of reliability and portability is quite disappointing.

$ ruby -w testt.rb
testt.rb:24: warning: `*' interpreted as argument prefix
    99.deadlock 0x7fadea3a6610: sleep:F(3)  - testt.rb:6
deadlock 0x7fadea3fe360: sleep:S (main) - testt.rb:15
testt.rb:15:in `write': Thread(0x7fadea3fe360): deadlock (fatal)
	from testt.rb:15:in `puts'
	from testt.rb:15:in `try_analyze'
	from testt.rb:13:in `each'
	from testt.rb:13:in `try_analyze'
	from testt.rb:24
	from testt.rb:22:in `upto'
	from testt.rb:22


----------------------------------------
http://redmine.ruby-lang.org

In This Thread

Prev Next