Interpreter cannot enter in the context from another thread

ruby-talk
1

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

Luis Lavena 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 Thomas (pg. 171 in *Programming Ruby 1.9*)

2

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.

···

On Sep 27, 5:30 pm, Ralph Shnelvar <ral...@dos32.com> 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 Lavena 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 Thomas (pg. 171 in *Programming Ruby 1.9*)

--
Luis Lavena

3

Luis,

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

···

On Sep 27, 5:30 pm, Ralph Shnelvar <ral...@dos32.com> 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 Lavena 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 Thomas (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 Lavena

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

Ralph

4

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

···

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

Luis,

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

> On Sep 27, 5:30 pm, Ralph Shnelvar <ral...@dos32.com> 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 Lavena 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 Thomas (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 Lavena

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

5

Chuck,

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

6

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 28, 5:57 am, Ralph Shnelvar <ral...@dos32.com> wrote:

--
Luis Lavena