Fiber variables

[Michael Fellinger]

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

 

[Robert Dober]

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

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

 

[Michael Fellinger]

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

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

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]

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
[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.