Hi,
Tired so just the most important parts first.
On Aug 2, 9:21 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> No there is not. Why do you think there is a race condition?
If the execution of the module takes longer than, say a few minutes,
the timestamp would be off of course. Long running HTTP requests are
pretty common these days thanks to stuff like comet.
> Yes. It was a design decision to be closer to Rails than Django in
> this respect. I think this is what is making web2py popular, more than
> anything else.
That's not django/rails that's more python vs ruby. In Ruby the
module/require work a lot different to python modules and the rails
people do have problems with that namespacing there because of the
silent reopening of classes.
> Can you provide an example of what you mean? I am pretty sure there is
> no leak.
_controlled = set()
def controlled(f):
_controlled.add(f)
return f
from lib import controlled
@controlled
def foo():
pass
If that code is reexecuted each time there would be a humongous memory
leak because over the func_globals even the temporary namespace is
preserved with everything in it.
> I disagree with "nobody knows how these idioms scale or behave"?
> We have been doing this for 2 years. We know very well how it works
> and scales.
> It actually works very well because as soon as a request is completed
> the environment is deleted, this is clean, avoids conflicts when
> multiple apps are running, and prevents memory leaks.
Python is not designed for short running code or throwaway modules.
Things can leak incredible fast and it's hard to spot. Here a piece
of code that would leak the hell out of a web2py application if used
inside one those throw-away environment things:
from collections import Container
class Foo(object):
def foo(self):
print "Meh"
Container.register(Foo)
That's maybe not the most obvious example because not many people will
use the ABC registry in those modules, but similar registration
systems are part of ORMs and many other systems. Even modules in the
standard library (csv dialects for instance)
> I do not see the problem. Files are automatically closed when the file
> object goes out of scope.
> Can you provide an example when it does not?
There is no such thing as a file going out of scope. The file is
closed as part of the object's __del__ method and that might or might
not be invoked. In cpython (and only in that python implementation)
there is a reference counter that often closes files when you think it
would, but even that's not always the case. Let me show you an
example where a file is leaked:
(Using a fake file here)
>>> class FakeFile(object):
... encoding = 'utf-8'
... write = lambda x, s: None
... def __del__(self):
... print "file deleted"
...
>>> class SortedLineWriter(object):
... def __init__(self, func, file):
... self.func = func
... self.file = file
... def write_lines(self, lines):
... for line in sorted(lines, key=self.func):
... self.file.write(line)
...
>>> def not_closing_directly():
... f = FakeFile()
... slw = SortedLineWriter(lambda x: x.decode(slw, 'ignore').lower
(), f)
...
KeyboardInterrupt
>>> def not_closing_directly():
... f = FakeFile()
... slw = SortedLineWriter(lambda x: x.decode(slw.file.encoding,
'ignore').lower(), f)
... slw.write_lines([])
...
>>> import gc
>>> not_closing_directly()
>>> gc.collect()
file deleted
5
As you can see, the file is not deleted right now, just after the gc
ran. This is standard behavior in pypy, jython and many others. In
cpython just if refcounting fails.
> I do not believe that is the case but I may be wrong. Can you provide
> an example of what you say?
Seems like I was misreading the code. repr() is properly used.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
