[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: rubyinline and rails - do they play nice

hemant

9/15/2006 7:51:00 PM

> You have to remember that Rails reloads it's controllers on every
> request in development mode. That's probably your problem.
>
> Couple of options I see:
>
> 1. Move the code into a file that won't be reloaded on every request
> (lib/ for example ?)
> 2. Use BackgrounDRb as you suggest
> 3. Web Services or something
>

Oh..yes, i forgot that. After running the stuff in production mode,
it worked nicely. so i guess it would be ok to use rubyinline in
rails.
4 Answers

hemant

9/15/2006 8:00:00 PM

0

On 9/16/06, hemant <gethemant@gmail.com> wrote:
> > You have to remember that Rails reloads it's controllers on every
> > request in development mode. That's probably your problem.
> >
> > Couple of options I see:
> >
> > 1. Move the code into a file that won't be reloaded on every request
> > (lib/ for example ?)
> > 2. Use BackgrounDRb as you suggest
> > 3. Web Services or something

I am already using Backgroundrb for several other stuff. But i am
curious, that how it will work with rubyinline? Ruby threads, should
handle it alright..theoretically(since backgroundrb uses ruby threads)

But, i would just ask opinions of Ezra on this. Because i feel, stuff
at my end needs some real optimization. These worker threads are damn
slow and i need to make them fast.

--
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.

Eric Hodel

9/18/2006 7:15:00 PM

0

On Sep 15, 2006, at 1:00 PM, hemant wrote:

> On 9/16/06, hemant <gethemant@gmail.com> wrote:
>> > 2. Use BackgrounDRb as you suggest
>
> I am already using Backgroundrb for several other stuff. But i am
> curious, that how it will work with rubyinline? Ruby threads, should
> handle it alright..theoretically(since backgroundrb uses ruby threads)
>
> But, i would just ask opinions of Ezra on this. Because i feel, stuff
> at my end needs some real optimization. These worker threads are damn
> slow and i need to make them fast.

Note that C code typically won't allow a thread switch, so the ruby
process will be blocked until the C method returns. Exceptions to
this include socket operations performed via the Ruby/C API and
manual calls of CHECK_INTS.

--
Eric Hodel - drbrain@segment7.net - http://blog.se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

hemant

9/19/2006 9:26:00 AM

0

On 9/19/06, Eric Hodel <drbrain@segment7.net> wrote:
<snip>
>
> Note that C code typically won't allow a thread switch, so the ruby
> process will be blocked until the C method returns. Exceptions to
> this include socket operations performed via the Ruby/C API and
> manual calls of CHECK_INTS.
>
</snip>

oh..so until if i call some method defined inside a rubyinline
function from a Ruby thread, the thread will block...till that method
finished execution?

I will keep in mind.

--
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.

Eric Hodel

9/19/2006 3:56:00 PM

0

On Sep 19, 2006, at 2:26 AM, hemant wrote:

> On 9/19/06, Eric Hodel <drbrain@segment7.net> wrote:
> <snip>
>>
>> Note that C code typically won't allow a thread switch, so the ruby
>> process will be blocked until the C method returns. Exceptions to
>> this include socket operations performed via the Ruby/C API and
>> manual calls of CHECK_INTS.
>>
> </snip>
>
> oh..so until if i call some method defined inside a rubyinline
> function from a Ruby thread, the thread will block...till that method
> finished execution?
>
> I will keep in mind.

So long as you stay inside the C function, yes. If you call back out
to ruby or use socket operations threads can be switched.

--
Eric Hodel - drbrain@segment7.net - http://blog.se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...