Avi Bryant escribió:
On Nov 26, 2005, at 6:59 PM, Esteban A. Maringolo wrote:
Now we must wait and authoritative answer for the side effects of no
using a weak container.
Well, the side effects are that memory use for an individual session
will grow faster. When the session itself is expired, the memory will
be reclaimed, so there's no danger of a long-term leak, but the runtime
footprint of your seaside application will be larger (and more tied to
the length of the session).
Ok, that's tolerable at this stage of the port.
What should be the expected behavior of weak dictionaries (or
equivalents) to be used in the registries?
Weak keys or weak values?
Can you write a SUnit test case, so I can make it pass?
I'm actually not convinced that expiring parts of a session via weak
dictionaries is that great an idea anyway. For one thing, some people
(especially Netstyle, who have some of the more heavily used Seaside
deployments out there) have seen some horrific CPU usage in Squeak when
the weak dictionaries grow too large. For another, the references
between continuations get messy enough that it's very hard to predict
whether and when any memory is actually getting collected. And
finally, expiring "old" pages can lead to some really bad user
experiences if they ever open up multiple windows on the same session
(since you can easily use one window to push the frontmost page of the
other window into expiry, at which point that other window is totally
unusable). So I'd like to find some other ways to manage long-running
sessions.
Some kind of undertaker process?
Best regards,
--
Esteban.
|
