Does a C extension running in a ruby-thread block all ruby threads
from running while it executes?
Thanks!
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator
Hi,
At Thu, 20 Sep 2007 04:22:09 +0900,
Wayne E. Seguin wrote in [ruby-talk:269902]:
Does a C extension running in a ruby-thread block all ruby threads
from running while it executes?
Yes.
Nobuyoshi N. wrote:
Hi,
At Thu, 20 Sep 2007 04:22:09 +0900,
Wayne E. Seguin wrote in [ruby-talk:269902]:Does a C extension running in a ruby-thread block all ruby threads
from running while it executes?Yes.
…except when you call back into ruby from your C code (right?). Then
the thread scheduler could get a chance to do its thing.
On 9/20/07, Wayne E. Seguin [email protected] wrote:
Does a C extension running in a ruby-thread block all ruby threads
from running while it executes?
You may be aware but you can use rb_thread_schedule() for letting your
Ruby threads run.
–
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
On Sep 19, 2007, at 17:56 , hemant wrote:
You may be aware but you can use rb_thread_schedule() for letting your
Ruby threads run.
hemant,
Actually… no I wasn’t.
So if I’m in a C extension and want to let the Ruby continue
processing can I do this:
- Async Operation
- rb_thread_schedule()
- Wait in C ext for async operation to complete (note that this C
extension is called from within a Ruby thread)
and the C ext would not block the other Ruby threads from that point?
Thank you very much!
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator
On Sep 19, 2007, at 17:15 , Joel VanderWerf wrote:
…except when you call back into ruby from your C code (right?).
Then the thread scheduler could get a chance to do its thing.
Joel,
Thank you for the response.
How do you call back? Is that the rb_thread_schedule() method?
Thank you again,
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator
On 9/20/07, Wayne E. Seguin [email protected] wrote:
processing can I do this:
- Async Operation
- rb_thread_schedule()
- Wait in C ext for async operation to complete (note that this C
extension is called from within a Ruby thread)and the C ext would not block the other Ruby threads from that point?
Yes, once you are finished with your Ruby thread and assuming no other
threads are scheduled to run, control will return back to the point in
C extension where you called rb_thread_schedule(). its basically
equivalent of Thread.pass in pure Ruby i suppose.
I hope it helps.
–
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
On 9/20/07, Wayne E. Seguin [email protected] wrote:
On Sep 19, 2007, at 17:15 , Joel VanderWerf wrote:
…except when you call back into ruby from your C code (right?).
Then the thread scheduler could get a chance to do its thing.
Joel,Thank you for the response.
How do you call back? Is that the rb_thread_schedule() method?
Or rb_funcall(). Basically any call that executes ruby code.
Ran into an “interesting” bug with a C extension once with
this: I used a global scratchpad on the C side and did ruby calls
from C to log stuff. Which let other ruby threads hit the C side and
screw up the scratchpad. Resulting in some messed up images.
On 9/20/07, Ilmari H. [email protected] wrote:
Or rb_funcall(). Basically any call that executes ruby code.
rb_funcall() is slow as shit, avoid it if you can.
Ran into an “interesting” bug with a C extension once with
this: I used a global scratchpad on the C side and did ruby calls
from C to log stuff. Which let other ruby threads hit the C side and
screw up the scratchpad. Resulting in some messed up images.
–
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
On 9/20/07, hemant [email protected] wrote:
Or rb_funcall(). Basically any call that executes ruby code.
rb_funcall() is slow as shit, avoid it if you can.
And logging touches disk, not like the 10 usec or so spent in rb_funcall
is going to do much difference there 
On Sep 20, 2007, at 11:06, Wayne E. Seguin wrote:
released just yet.
Suggestions are most welcome
Most of the C functions in IO will allow threads to be switched.
Eventually they run into rb_thread_schedule(). You can get non-
blocking IO without writing C code, IO can handle that for you.
On Sep 20, 2007, at 13:40 , Ilmari H. wrote:
And logging touches disk, not like the 10 usec or so spent in
rb_funcall
is going to do much difference there
Actually the reason that I brought this question up is that I am
working on an asynchronous logger for Ruby whose main purpose is to
remove the Blocking IO time from the equation in order to greatly
speed up production apps running on a POSIX compliant OS.
The project is on rubyforge as “AlogR” but is not ready to be
released just yet.
Suggestions are most welcome 
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator
On 9/20/07, Wayne E. Seguin [email protected] wrote:
The project is on rubyforge as “AlogR” but is not ready to be
released just yet.
Suggestions are most welcome
You might mention this to Kirk H… He 's already written an
asynchronous
logger.
On Sep 20, 2007, at 15:27 , Eric H. wrote:
Most of the C functions in IO will allow threads to be switched.
Eventually they run into rb_thread_schedule(). You can get non-
blocking IO without writing C code, IO can handle that for you.
Can you provide me with an example or point me to a url to RTFM?
Thanks!
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator
On Sep 20, 2007, at 12:36, Wayne E. Seguin wrote:
On Sep 20, 2007, at 15:27 , Eric H. wrote:
Most of the C functions in IO will allow threads to be switched.
Eventually they run into rb_thread_schedule(). You can get non-
blocking IO without writing C code, IO can handle that for you.Can you provide me with an example or point me to a url to RTFM?
io/nonblock.rb and IO#read_nonblock should get you started.
On Sep 20, 2007, at 15:41 , Francis C. wrote:
You might mention this to Kirk H… He 's already written an
asynchronous
logger.
Thank you for the suggestion. I talk with him just about every day
The goals of AlogR are disjoint from analogger.
~Wayne
s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator