I am not sure, if this deserves a response, but i was experimenting with
rubyinline and was trying to write some of the controller code in C.
class FameController < ApplicationController
inline do |builder|
builder.c "
long factorial(int max) {
int i=max, result=1;
while (i >= 2) { result *= i--; }
return result;
}"
end
def my_factorial_fame
my_fame = factorial(1)
end
end
Now good thing about the above controller code is that, it works. And the
bad news is, it works only once...upon the next refresh it says:
require on /home/gnufied/.ruby_inline/Inline_FoobarController_cb89.so failed
I am not sure, how it translates into English. but SO file is there in
the location mentioned. I guess, its completely crazy to attempt this.
But i need such a thing.
I have 3000 lines of ruby code that does some very complicated
mathematical calculations and its slow. worst it generates
segmentation faults(Probably writing it in C will
generate some more of seg faults and no it was not written by me. I
would have used GSL in places at least.)
Now...what are my options? this 3000 line code is a rails controller code.
Another question is, can i use rubyinline in background worker threads
created by backgroundrb plugin?
PS: Sorry for a bag of mixed questions.
···
--
---
The Road goes ever on and on
Down from the door where it began.
Now far ahead the Road has gone,
And I must follow, if I can,
Pursuing it with eager feet,
Until it joins some larger way
Where many paths and errands meet.
And whither then? I cannot say.
Now good thing about the above controller code is that, it works. And the
bad news is, it works only once...upon the next refresh it says:
require on /home/gnufied/.ruby_inline/Inline_FoobarController_cb89.so failed
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
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.
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.
···
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
--
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.
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.
···
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.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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.
···
On 9/19/06, Eric Hodel <drbrain@segment7.net> wrote:
--
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.
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.
···
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.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant