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.
···
--
Nobu Nakada
You may be aware but you can use rb_thread_schedule() for letting your
Ruby threads run.
···
On 9/20/07, Wayne E. Seguin <wayneeseguin@gmail.com> wrote:
Does a C extension running in a ruby-thread block all ruby threads
from running while it executes?
--
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
Nobuyoshi Nakada 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.
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
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:56 , hemant wrote:
You may be aware but you can use rb_thread_schedule() for letting your
Ruby threads run.
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 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.
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.
···
On 9/20/07, Wayne E. Seguin <wayneeseguin@gmail.com> wrote:
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?
--
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
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, Wayne E. Seguin <wayneeseguin@gmail.com> 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?
> > ...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.
rb_funcall() is slow as shit, avoid it if you can.
···
On 9/20/07, Ilmari Heikkinen <ilmari.heikkinen@gmail.com> wrote:
On 9/20/07, Wayne E. Seguin <wayneeseguin@gmail.com> wrote:
> On Sep 19, 2007, at 17:15 , Joel VanderWerf wrote:
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.
And logging touches disk, not like the 10 usec or so spent in rb_funcall
is going to do much difference there 
···
On 9/20/07, hemant <gethemant@gmail.com> wrote:
On 9/20/07, Ilmari Heikkinen <ilmari.heikkinen@gmail.com> wrote:
> On 9/20/07, Wayne E. Seguin <wayneeseguin@gmail.com> 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.
>rb_funcall() is slow as shit, avoid it if you can.
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 Sep 20, 2007, at 13:40 , Ilmari Heikkinen wrote:
And logging touches disk, not like the 10 usec or so spent in rb_funcall
is going to do much difference there
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 11:06, Wayne E. Seguin wrote:
On Sep 20, 2007, at 13:40 , Ilmari Heikkinen wrote:
And logging touches disk, not like the 10 usec or so spent in rb_funcall
is going to do much difference thereActually 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
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
You might mention this to Kirk Haines. He 's already written an asynchronous
logger.
···
On 9/20/07, Wayne E. Seguin <wayneeseguin@gmail.com> wrote:
On Sep 20, 2007, at 13:40 , Ilmari Heikkinen wrote:
> And logging touches disk, not like the 10 usec or so spent in
> rb_funcall
> is going to do much difference thereActually 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
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 15:27 , Eric Hodel 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.
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
···
On Sep 20, 2007, at 15:41 , Francis Cianfrocca wrote:
You might mention this to Kirk Haines. He 's already written an asynchronous
logger.
io/nonblock.rb and IO#read_nonblock should get you started.
···
On Sep 20, 2007, at 12:36, Wayne E. Seguin wrote:
On Sep 20, 2007, at 15:27 , Eric Hodel 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?
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars