Fiber variables

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

···

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

--
http://ruby-smalltalk.blogspot.com/

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

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

···

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

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

···

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:

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