[ruby-talk:14731] Re: interfaces to some existing C/C++ code?

>===== Original Message From "Andrew Dalke" <[e-mail]> =====
>Hello,
>
>My previous post:
>>[Synopsis: a C library I work with uses opaque integer handles to
>>refer to internal toolkit objects.  It also requires correct
>>deallocation order for some of the objects.  I can write a
>>wrapper layer for the C implementation of Python to have it do the
>>correct automatic garbage collection, but can't figure out how to
>>use Ruby for the same task, because finalization order isn't
>>guaranteed and because it assumes C extension types are always
>>through pointers.]
>
>I sent this post a few days ago but haven't seen a response
>yet.  Am I missing someone's reply?  Or is there something I can
>do to restate my question in a way to make it more likely to
>elicit a response?

I think the problem was that it was a long, detailed question
that is begging for a long, detailed answer.  Which takes more
energy than people feel up to.  I know it has been sitting on
my in-box, I keep meaning to do it, but never quite get the
energy up.  I suspect I am not alone in that...

Anyways the basic problem is the one that I addressed at:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/14400

and it will be issues for many languages.  Like Java, Smalltalk,
Lisp...

For your example you had some specific issues.  One answer
is to have a C wrapper that works only through pointers and
can figure out how to destroy in order despite the fact that
they will be freed randomly.  Then wrapping in Ruby is easier.
(There are other answers that you could come up with.  None
of which are pretty.)

>The same is true for my question on how well Ruby's threading
>mechanism interoperates with native threading packages like
>pthreads.  (That thread is titled "interfaces to some existing
>pthread code.")

I don't remember that off-hand, but the answer is "not well".
Ruby implements its own internal threading model at the
moment.  This may change.

Cheers,
Ben