From: Eleanor McHugh <eleanor@...>
Date: 2009-09-06T05:45:29+09:00
Subject: Re: Problems with cross-thread violation

On 5 Sep 2009, at 17:07, Gin Mendi wrote:
> Eleanor McHugh wrote:
>>  loop do
>>  end
>
> sweet thanks! Still trying to get a hang of ruby so tips like this are
> great for me ;)

I've been using Ruby for eight years now and I still find new ways of  
expressing myself - it's a rich language :)

> I'm unsure if get_live_feed uses a seperate thread. I just have the  
> dll
> and no source. If get_live_feed does use a seperate thread how would I
> make a seperate feed handle? Does that mean I need to declare a new
> callback and pass that each time I call live feed?

Not necessarily, but it's certainly an experiment I'd consider as part  
of taming the problem. If you know C reasonably well I also recommend  
taking a peak through /ext/dl in the Ruby sources. That's not for the  
faint-hearted though.

> I tried using a variable but I still get the cross-thread violation. I
> noticed though if I do not use the structure and use other methods to
> display the data in the pointer I get more calls out of the callback
> before I hit the cross-thread violation. Just wondering was it wrong  
> to
> use a constant for the callback?

It's best not to use a constant unless the object it refers to is  
intended to last for the lifetime of the program. For one thing  
constants in Ruby won't prevent assignment, nor are the objects they  
refer to proof against state changes. If you really want constant  
behaviour in some sense you need to freeze the object in question.

I'm uncertain whether this has any bearing on your particular callback  
problem, but freezing the callback object would be yet another  
diagnostic tool worth trying as any subsequent attempt to modify it  
would raise an exception.

> I did some research on garbage collection. Is turning off garbage
> collection simply GC.disable? If I do disable garbage collection does
> that mean I have to run the free method on my pointers or put some  
> extra
> code to free up memory?

No, it just means that while garbage collection is disabled your  
unreferenced objects will remain in memory. Once you reenable it all  
those dead objects will then be dealt with during the next collection  
cycle, including freeing up any memory associated with DataPtr objects  
you may have created with DL::malloc.

> Thanks again for all the help :)

That's what we're here for :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason