On Sun, 4 Feb 2007, Daniel DeLorme wrote:
Interesting. I had though about db connections but hadn’t followed the
reasoning through to file descriptors and other shared resources. True this
might be quite tricky and problematic but, as khaines said, not necessarily
a showstopper.
i don’t think it’s a show stopper for a roll your own solution for a
specifc
app, but it’s impossible from outside and ap to know, for instance, if
the
code that’s being wrapped did something like ‘flush fd 7’ or not. here’s
a
simple example: say the code you are about to fork did this
lockfile.flock File::LOCK_EX
know you cannot fork. well, you can, but the children cannot inherit
nor can
reaquire this resource. there are many other resources with similar
patterns:
binding to a socket, for example.
Indeed, I imagine (hope) that the code of a .so file would be shared between
processes. But I very much doubt the same holds true for .rb files. And I
doubt that compiled modules are more than a small fraction of the code.
in fact linux will cache .rb files: you can prove this to yourself
thusly by
running a find on ‘/usr’. then do it again, the second time it will be
loads
faster because the filesystem caches pages (fs dependant of course, but
this
will be true on 90% of linux boxes). the pages only get flushed if
they’re
marked dirty (written to) which in the case of ruby libs is virtually
never.
this bevahiour actually is buggy when nfs is used to mount the .rb
files. on
our cluster an install of a ruby library sometimes results in two
version on
the machine: one in memory and one on disk. for some reason the cache
gets
corrupt via nfs and the new library never takes effect until a reboot.
the
point here being the .rb files are definitely cached.
break if Process.fork.nil?
end
require “/path/to/rails/app/config/environment.rb”
sleep 10and tell me which one you like better
the second, because the db connection will work in it 
seriously, i think it’ll be hard to track all the resources - but it
would be
great to see it done!
cheers.
-a