Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Multi-threaded C++, new, and xmalloc

Reply
Thread Tools

Multi-threaded C++, new, and xmalloc

 
 
Tim Hollingsworth
Guest
Posts: n/a
 
      11-23-2006
Hello

I have a C++ application with an embedded ruby interpreter. I have
overridden the new() operator globally:

void* operator new (size_t size)
{
void *p=xmalloc(size);
if (p==0) // did malloc succeed?
throw std::bad_alloc(); // ANSI/ISO compliant behavior
return p;
}

void operator delete (void *p)
{
xfree(p);
}

This keeps the GC informed about allocations. It has been working
wonderfully for months but just recently the program has been crashing
badly. I've narrowed it down to allocations on some worker threads on
the C++ side. While they do not interact with ruby directly, any
allocations will obviously be routed through xmalloc, and hence might
cause memory corruption.

Does anybody have a clue how to fix this?

cheers
Tim

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Tim Hollingsworth
Guest
Posts: n/a
 
      11-23-2006
I suppose the obvious answer is to synchronise access to the xmalloc
function... or to mash the worker threads into the main thread via my
message pump. I'll try the former.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Tim Hollingsworth
Guest
Posts: n/a
 
      11-23-2006
Tim Hollingsworth wrote:
> I suppose the obvious answer is to synchronise access to the xmalloc
> function...


ok so that didn't work. To go down that road would probably require
synchronising all access to the ruby interpreter.


--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Edwin Fine
Guest
Posts: n/a
 
      11-23-2006
I'm sure you know this, but just in case: the embedded Ruby interpreter
does not work well with a multi-threaded application because it has
global variables and therefore cannot be re-entrant.

Quote:
"ruby is not thread-safe. If you embed ruby into a multi-threaded
application then you will need to semaphore protect all access to ruby.
Warning: Insufficient semaphore protection can be hard debuggable." -
http://metaeditor.sourceforge.net/embed/

You would have to somehow organize a separate instance of each Ruby
interpreter on a per-thread basis, or have a locking decorator that
intercepts all calls to Ruby using a mutex. Or something like that. I
believe that Ruby 2 is aiming to overcome the lack of re-entrancy. I
wonder when Ruby 2's day will be (sorry, Mick; cringes, ducks and runs).


--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Paul Brannan
Guest
Posts: n/a
 
      11-24-2006
On Thu, Nov 23, 2006 at 08:38:30PM +0900, Tim Hollingsworth wrote:
> This keeps the GC informed about allocations.


I think this is probably unnecessary. You're informing the GC about
allocations for memory it doesn't control. The GC may be invoked more
often, but it won't be able to free any more memory. If you don't use
xmalloc, then the GC should still function correctly, and will still
try to free memory if malloc fails (though I suppose it's a little
unfortunate that malloc doesn't typically fail on many operating
systems).

Paul



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
xmalloc.c - my xmalloc vippstar@gmail.com C Programming 11 02-20-2008 12:34 AM
xmalloc string functions Kelsey Bjarnason C Programming 240 02-07-2008 04:11 AM
xmalloc Malcolm McLean C Programming 52 06-27-2007 08:44 PM
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM
[OT?] xmalloc Jeff C Programming 10 07-07-2003 05:14 PM



Advertisments