Interpreter cannot enter in the context from another thread

This is a continuation of the thread:
Re: Segmentation Fault; more info?

Luis L. said:

“Please note that Ruby 1.8.x is not multithread and that the
interpreter cannot enter in the context from another thread.”

Could use please explain this further?

Unless I am missing something, 1.8.7 implements green threads … at
least according to Dave T. (pg. 171 in Programming Ruby 1.9)

On Sep 27, 5:30 pm, Ralph S. [email protected] wrote:

Could use please explain this further?

Unless I am missing something, 1.8.7 implements green threads … at least according to Dave T. (pg. 171 in Programming Ruby 1.9)

Yes, but you’re using FXRuby which is a C component.

Since you haven’t provided a sample code that shows the segmentation
fault. I must tackle all the possible issues, including the spawn of
threads by FXRuby and using Ruby-based callbacks.

So, Ruby green threads are OK, as long you don’t mix them with real
threads. In your post you mention “4 different threads”

We are just guessing all due your lack of code.

Luis,

Monday, September 27, 2010, 2:45:09 PM, you wrote:

LL> On Sep 27, 5:30 pm, Ralph S. [email protected] wrote:

[Note: parts of this message were removed to make it a legal post.]

This is a continuation of the thread:
Re: Segmentation Fault; more info?

Luis L. said:

“Please note that Ruby 1.8.x is not multithread and that the
interpreter cannot enter in the context from another thread.”

Could use please explain this further?

Unless I am missing something, 1.8.7 implements green threads … at least according to Dave T. (pg. 171 in Programming Ruby 1.9)

LL> Yes, but you’re using FXRuby which is a C component.

LL> Since you haven’t provided a sample code that shows the segmentation
LL> fault. I must tackle all the possible issues, including the spawn of
LL> threads by FXRuby and using Ruby-based callbacks.

LL> So, Ruby green threads are OK, as long you don’t mix them with real
LL> threads. In your post you mention “4 different threads”

LL> We are just guessing all due your lack of code.

LL> –
LL> Luis L.

Could you please explain what you mean by “interpreter cannot enter in
the context from another thread.”

Ralph

Chuck,

CR> A native thread (e.g. one created by the FXRuby C extension) cannot
call back into the ruby runtime context to execute more ruby code
without causing lots of pain.

Ok … now I’m really confused.

FXRuby has a method called addTimeout (Yes … it is camel cased).

addTimeout allows you to call back to a Ruby method; either once or
repeatedly … e.g.

timeout_ = @app.addTimeout(1000, method_, :repeat => true)

method_ will be invoked once every second in the same thread as the call
to addTimeout. This is well documented and seems to work flawlessly.

Is this what you are talking about?

Ralph

On Sep 28, 5:57 am, Ralph S. [email protected] wrote:

Ok … now I’m really confused.

We are more because you’re not showing us what code is generating the
fault. All we are trying to do is help you and we are taking guesses
to all the possible issues.

FXRuby has a method called addTimeout (Yes … it is camel cased).

addTimeout allows you to call back to a Ruby method; either once or repeatedly … e.g.

timeout_ = @app.addTimeout(1000, method_, :repeat => true)

method_ will be invoked once every second in the same thread as the call to addTimeout. This is well documented and seems to work flawlessly.

Is this what you are talking about?

We don’t know because you haven’t show any single line of code.
Perhaps it is, perhaps is not, but until you show some code, we can’t
help further.

On Sep 27, 2010, at 3:55 PM, Ralph S. wrote:

Re: Segmentation Fault; more info?
LL> Yes, but you’re using FXRuby which is a C component.
LL> –
LL> Luis L.

Could you please explain what you mean by “interpreter cannot enter in the context from another thread.”

A native thread (e.g. one created by the FXRuby C extension) cannot call
back into the ruby runtime context to execute more ruby code without
causing lots of pain.

You should show us some code.

cr