Multi-threaded C++, new, and xmalloc

T

Tim Hollingsworth

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
 
T

Tim Hollingsworth

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.
 
T

Tim Hollingsworth

Tim said:
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.
 
E

Edwin Fine

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).
 
P

Paul Brannan

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top