On Wed Mar 14, 2007 at 08:14:36PM -0400, Michael Gorsuch wrote:
> carmen - I'm not sure _how_ much this will really help you, but I
> recently explored a similar issue with an internal Camping app.
>
> In summary, I needed to make sure that all calls to a specific
> controller were always executed serially. i.e. - if two calls came in
> at approximately the same time, the second call could not run until
> the first one finished.
thanks. ive got the PP thread chapter bookmarked, and planned to get into it.
your example is nice and simple..
mainly i am unclear on what the current concurrency model is - its fairly
obvious with rails since for whatever reason it's more popular so theres tons
of blogs discussing it, but i cant find anything except a CHANGELOG entry in
1.3 mentioning some method is thread-safe (but does this extend to the entire
framework?)
my brief experiments with subjective request timings using 2 browsers, along
with stats from httperf, had me thinking everything is already serialized. and
here youre suggesting the opposite...
which is it!? i seem to recall a 'dangerous' switch somewhere in mongrel or
rails that disabled the explicit serialization.
fwiw, heres my mongrel configurator:
if __FILE__ == $0
Yard.create
config = Mongrel::Configurator.new :host => (ARGV[0] || "0.0.0.0") do
listener :port => (ARGV[1] || 80) do
uri "/", :handler =>
Mongrel::Camping::CampingHandler.new(Camping::Reloader.new(__FILE__))
uri '/s/', :handler =>
Mongrel::DirHandler.new(File.dirname(__FILE__)+"/s")
trap("INT") { stop }; run
end
end
config.join
end
>
> This was not a problem: I just included the 'thread' library and
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
