Thanks Armin, my command below: On Aug 2, 3:18 pm, Armin Ronacher <armin.ronac...@active-4.com> wrote: > 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.
True. but I would not call it a race condition. We timestamp everything with the time when a request arrives, not when it is processed, unless specified otherwise (datetime.now() instead of request.now) > > 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. True but I believe we never do that in web2py. It is also true that nothing prevent the user from doing it but the same would be true with other frameworks. > > 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. Yes but because all relevant application code is executed within a context and there are no references outside the context to stuff inside the context, when a request is completed, the context is deleted and everything should be garbage collected. Anyway. I agree with you it would be better to always close files explicitly. I will do so unless omebody sends me a patch first. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
