On 9 Mar 2011, at 19:34, 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. > I think you'd find that drb is very easy to use. > 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 doubt it - while with something like passenger your workers do share initial resources (since they are forked from the application spawner (at least by default)), that's a one way thing: if one worker changes the state of the object then that happens in that process only. You do share file descriptors, but that's more likely to be a nuisance - if two workers try use the same socket as the same time, chaos will ensue Fred > > -- > Posted via http://www.ruby-forum.com/. > > -- > 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. > -- 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.
