Multi-threaded C++, new, and xmalloc

Discussion in 'Ruby' started by Tim Hollingsworth, Nov 23, 2006.

  1. 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/.
    Tim Hollingsworth, Nov 23, 2006
    #1
    1. Advertising

  2. 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/.
    Tim Hollingsworth, Nov 23, 2006
    #2
    1. Advertising

  3. 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/.
    Tim Hollingsworth, Nov 23, 2006
    #3
  4. Tim Hollingsworth

    Edwin Fine Guest

    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/.
    Edwin Fine, Nov 23, 2006
    #4
  5. Tim Hollingsworth

    Paul Brannan Guest

    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
    Paul Brannan, Nov 24, 2006
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeff

    [OT?] xmalloc

    Jeff, Jul 1, 2003, in forum: C Programming
    Replies:
    10
    Views:
    1,234
    Dan Pop
    Jul 7, 2003
  2. ian douglas
    Replies:
    2
    Views:
    981
    Randy Howard
    Jul 30, 2004
  3. Malcolm McLean

    xmalloc

    Malcolm McLean, Jun 23, 2007, in forum: C Programming
    Replies:
    52
    Views:
    1,781
    Ben Pfaff
    Jun 27, 2007
  4. Kelsey Bjarnason

    xmalloc string functions

    Kelsey Bjarnason, Jan 27, 2008, in forum: C Programming
    Replies:
    240
    Views:
    3,468
  5. xmalloc.c - my xmalloc

    , Feb 15, 2008, in forum: C Programming
    Replies:
    11
    Views:
    918
Loading...

Share This Page