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


 

Forums >

comp.lang.ruby

Fiber variables

Michael Fellinger

6/15/2008 9:43:00 AM

Hi list,

I've been doing some playing with Fibers as a replacement of Thread
for usage in Ramaze, and as I'm not the most knowledgable about this
issue I'd like to request some code review from you guys.

The code in question with some simple usage is at:
http://p.ramaz...

I'm not sure if i would run into any issues with this approach or why
it hasn't been done in the fiber library already, but would you see
this as a good use of fibers, to avoid having to pass state around for
every component in the application/framework?

My use case here is that you get a request from servers, possibly
event driven, which just doesn't work well together with threading as
it's done in ruby. So i take the request, create a couple of objects
and put them into the fiber instance, to be accessed by Fiber.current.
So it's kind of a reimplementation of what Thread.current[:a] = 1
would do, but much more lightweight.

Thanks in advance, please let me know when you have any more questions
about this mail
^ manveru
3 Answers

Robert Dober

6/16/2008 10:15:00 AM

0

On Sun, Jun 15, 2008 at 11:43 AM, Michael Fellinger
<m.fellinger@gmail.com> wrote:
> Hi list,
>
> I've been doing some playing with Fibers as a replacement of Thread
> for usage in Ramaze, and as I'm not the most knowledgable about this
> issue I'd like to request some code review from you guys.
>
> The code in question with some simple usage is at:
> http://p.ramaz...
>
> I'm not sure if i would run into any issues with this approach or why
> it hasn't been done in the fiber library already, but would you see
> this as a good use of fibers, to avoid having to pass state around for
> every component in the application/framework?
>
> My use case here is that you get a request from servers, possibly
> event driven, which just doesn't work well together with threading as
> it's done in ruby. So i take the request, create a couple of objects
> and put them into the fiber instance, to be accessed by Fiber.current.
> So it's kind of a reimplementation of what Thread.current[:a] = 1
> would do, but much more lightweight.
>
> Thanks in advance, please let me know when you have any more questions
> about this mail
> ^ manveru
>
>

I did not feel qualified to reply, but obviously nobody does :(. Well
it seems a simple and quite efficient solution to your problem. It
somehow is *obviously* right, I beware of the obvious but could not
find any gotchas.

Would it be possible that a different approach like an explicit hash
in Fiber would lead to cleaner code?

YourFiber = Class::new Fiber
attr_reader :data
def initialize *args, &blk
super(*args, &blk)
@data = {}
end
end

I know the resulting code would be a little be less elegant as you
would have all the
Fiber.current.data[]
instead of Fiber.current[]

Going back to your original idea, why not using Forwardable?

class Fiber
extend Forwardable
def_delegators :@data, :[], :[]=
alias_method :__old__init__, :initialize
def initialize *args, &blk
__old__init__ *args, &blk
@data = {}
end
end
class << Fiber
extend Forwardable
def_delegators :current, :[], :[]=
end


Just my 2cents

HTH
Robert











--
http://ruby-smalltalk.blo...

---
As simple as possible, but not simpler.
Albert Einstein

Michael Fellinger

6/16/2008 12:41:00 PM

0

On Mon, Jun 16, 2008 at 7:14 PM, Robert Dober <robert.dober@gmail.com> wrote:
> On Sun, Jun 15, 2008 at 11:43 AM, Michael Fellinger
> <m.fellinger@gmail.com> wrote:
>> Hi list,
>>
>> I've been doing some playing with Fibers as a replacement of Thread
>> for usage in Ramaze, and as I'm not the most knowledgable about this
>> issue I'd like to request some code review from you guys.
>>
>> The code in question with some simple usage is at:
>> http://p.ramaz...
>>
>> I'm not sure if i would run into any issues with this approach or why
>> it hasn't been done in the fiber library already, but would you see
>> this as a good use of fibers, to avoid having to pass state around for
>> every component in the application/framework?
>>
>> My use case here is that you get a request from servers, possibly
>> event driven, which just doesn't work well together with threading as
>> it's done in ruby. So i take the request, create a couple of objects
>> and put them into the fiber instance, to be accessed by Fiber.current.
>> So it's kind of a reimplementation of what Thread.current[:a] = 1
>> would do, but much more lightweight.
>>
>> Thanks in advance, please let me know when you have any more questions
>> about this mail
>> ^ manveru
>>
>>
>
> I did not feel qualified to reply, but obviously nobody does :(. Well
> it seems a simple and quite efficient solution to your problem. It
> somehow is *obviously* right, I beware of the obvious but could not
> find any gotchas.
>
> Would it be possible that a different approach like an explicit hash
> in Fiber would lead to cleaner code?

I actually ended up with just subclassing Fiber:
http://p.ramaz...

> YourFiber = Class::new Fiber
> attr_reader :data
> def initialize *args, &blk
> super(*args, &blk)
> @data = {}
> end
> end
>
> I know the resulting code would be a little be less elegant as you
> would have all the
> Fiber.current.data[]
> instead of Fiber.current[]
>
> Going back to your original idea, why not using Forwardable?
>
> class Fiber
> extend Forwardable
> def_delegators :@data, :[], :[]=
> alias_method :__old__init__, :initialize
> def initialize *args, &blk
> __old__init__ *args, &blk
> @data = {}
> end
> end
> class << Fiber
> extend Forwardable
> def_delegators :current, :[], :[]=
> end
>
>
> Just my 2cents
>
> HTH
> Robert

Roger Pack

6/16/2008 7:59:00 PM

0

Michael Fellinger wrote:
> Hi list,
>
> I've been doing some playing with Fibers as a replacement of Thread
> for usage in Ramaze, and as I'm not the most knowledgable about this
> issue I'd like to request some code review from you guys.
>
> The code in question with some simple usage is at:
> http://p.ramaz...
>
> I'm not sure if i would run into any issues with this approach or why
> it hasn't been done in the fiber library already, but would you see
> this as a good use of fibers, to avoid having to pass state around for
> every component in the application/framework?

I ended up wrapping evented mongrel calls with a Fiber and it seemed to
work like a charm for my limited requests. Couple this with an evented
DB and I think it has a lot of potential :)
[This is what I was trying to do with ramaze on the group the other day,
but had to give up since it wasn't user friendly to beginners].

http://rubyforge.org/pipermail/eventmachine-talk/2008-June/0...
lists a few code snippets.

--
Posted via http://www.ruby-....