Re: [Swig-user] Ruby %trackobjects problem

[Roy S. <ro...@mi...>]

Charlie,

No problems there.  Obviously I was a little busy for a couple days.  
What if we had a SWIG command-line parameters (defines?) that could 
allow us to specify a main module vs. a non-main module?  This would 
allow us to produce code for projects such as ours without using a 
custom post-SWIG step.  Something like -dSHARED_MODULE or some-such.  It 
would be reasonable to have main module be the default behavior for 
backwards compatibility.

Roy

Charlie Savage wrote:
> Thanks Marcelo for the tip.
>
> The type information is stored in a global, read only variable called 
> $swig_runtime_data_type_pointer2 and accessed via  
> rb_gv_get/rb_gv_set.  Note there is no locking, so either Ruby is 
> using a single thread to load modules or this isn't thread safe.
>
> Anyway, it seems like we should do the same thing for the tracking 
> object hash.  The downside is that it becomes visible from Ruby 
> (although we could use an instance variable on the Class Object that 
> doesn't start with a @ to hide it).  The upside is that it will work 
> across all loaded modules.
>
> It won't take long to put together a patch to do this.  The other 
> issue will take more effort, and require a change to how free 
> functions are handled.  Unfortunately, I don't have any time to look 
> at this right now, so it might be a week or so.  Is that ok Roy?  But 
> we'll get this into the next SWIG release for sure.
>
> Charlie
>
> Marcelo Matus wrote:
>> Charlie Savage wrote:
>>
>>> Hi Roy,
>>>
>>> Could you give me a little background on your setup?  So you have 
>>> 144 separate files, each being its own module?  And in some cases 
>>> you may create object1 in module1 and pass it as a parameter to 
>>> method2 in module2?
>>>
>>> If that's the case, yup, I can see why you might run into trouble.  
>>> Do you have a proposed solution?
>>>
>>> I'm not sure where we could hook in a shared hash table.   Anyone 
>>> have any thoughts on this?
>>
>> You can do the same that John Lenz did with the runtime library, ie, 
>> create a single 'table object' in the target
>> language, so, you can share it between all the modules.
>>
>> Take a look at the runtime implementation, the idea is that when you 
>> load a module, you try first
>> to load the runtime table object from the target language, if is not 
>> there, you create one
>> and save the object/pointer in the target language space. Then, when 
>> another module
>> is loaded, it will pick the previously created runtime table, and 
>> modify it if need it.
>>
>> In this way, only a single runtime table object exist, and it is 
>> shared between all the modules.
>>
>>
>> Marcelo
>>
>>
>>>
>>> I guess we could make the hash table a global (instead of static), 
>>> check to see if its initialized when a module is loaded, and if not 
>>> create it.  Could get a race condition though, unless Ruby uses a 
>>> single thread to load all these modules, or some locking is put in 
>>> place (there is a lock if I remember correctly in the directors code).
>>> Are there any other shared items between these modules you might run 
>>> into issues?
>>> While we are at it, we should address the issue that nerochiaro 
>>> brought up where you can run into trouble because Ruby recycles 
>>> object ids.  See this thread: 
>>> http://sourceforge.net/mailarchive/message.php?msg_id=14957445.  Do 
>>> you use any free or mark functions?
>>>
>>> Charlie
>>>
>>>
>>>
>>> Roy Sutton wrote:
>>>
>>>> There's a teensy problem in the ruby trackobjects code...  The hash 
>>>> that stores all the pointers that have been allocated is only file 
>>>> global, not project global.  So, a pointer allocated in one file is 
>>>> not available as the same ruby object when returned by another 
>>>> file.  The project we're working (wxWindows/Widgets) on has 
>>>> approximately 144 files with a large class hierarchy.  Any solution 
>>>> that doesn't share the hash table is just asking for trouble!  I'll 
>>>> try working up a patch if I can but maybe someone else already has 
>>>> a solution for this?
>>>>
>>>> Roy
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>>>> language
>>>> that extends applications into web and mobile media. Attend the 
>>>> live webcast
>>>> and join the prime developer group breaking into this new coding 
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
>>>>
>>>> _______________________________________________
>>>> Swig-user mailing list
>>>> Swi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>>>
>>>>
>>
>>
>>