Fiber variables

Ruby
1

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.ramaze.net/1618

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

2

On Sun, Jun 15, 2008 at 11:43 AM, Michael F.
[email protected] wrote:

it hasn’t been done in the fiber library already, but would you see
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.blogspot.com/

As simple as possible, but not simpler.
Albert Einstein

3

On Mon, Jun 16, 2008 at 7:14 PM, Robert D. [email protected]
wrote:

would do, but much more lightweight.
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.ramaze.net/1627

4

Michael F. 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.ramaze.net/1618

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 :slight_smile:
[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/001881.html
lists a few code snippets.