On Mar 9, 2:34 pm, Chad Johnson <li...@ruby-forum.com> wrote:
> Frederick Cheung wrote in post #986539:
>
> > On 9 Mar 2011, at 17:47, Chad Johnson <li...@ruby-forum.com> wrote:
>
> >>            Thread.current["mycount"] = count
> >>            count += 1
> >>          }
> >>        end
>
> > This looks thread dangerous to me - i don't think += is atomic.
> >> variable**. For instance, maybe whatever spawns the ruby process to
> >> serve httpd process could hold the variable count in its scope, and then
> >> the ruby processes spawned for httpd processes could then access that
> >> variable.
>
> Just example code I pulled from someone online. I'd never actually use
> this, and my stuff would be as thread-safe as possible.
>
> > Personally, if I had to do this, I'd these objects in a separate
> > long-lived process (or processes) and have your controller actions talk
> > to these processes (exactly how depends on what you'll be doing, you
> > might consider drb, message queues etc)
>
> You're talking about something like a daemon to act as a proxy, and
> I'd communicate with it via some protocol I define? That was my thought
> too, but it's extra work, and I was trying to avoid spending the extra
> time on this and just use the FTP connection directly.
>
> So, regardless of whether this is a good or bad idea (I will assess that
> later), is there any way to directly access a shared resource object?

I don't think there's any *question* this is a bad idea. For instance,
how are you planning on arbitrating the FTP connections to avoid
situations like this:

Process 1: cd foo
Process 2: cd bar
Process 1: put somefile.txt

Now somefile.txt is in the wrong place... There are similar issues
with keeping the connections alive, etc plus the *total* mess that
happens once you move beyond a single box.

In the Stackoverflow question, you mention that you're only listing
directories. Maybe it would make more sense to write a fairly basic
proxy in a smaller framework (Sinatra maybe?) that just takes JSON
specifying what to list and spits back results? Such a server would
solve the issues mentioned above, and could even do basic caching.

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en.

Reply via email to