Well... this:
Sometimes unavoidable bad things happen and cannot be mitigated.
is a tautology. Also, not an excuse for exercising good judgement in
architecture
and design. :-) I know you probably understand that.
I'm not saying "pickling is bad" -- it has it's uses -- perhaps I am
saying there is a dangerous "siren's call" there.... You have to be very
careful in also assessing the costs of using it in a design. Using
it as
discussed certainly seems to violate one of the first principles of
information
systems design -- put simply (and slightly inaccurately):
"keep your data and your program separate" --
so one might assume that it has some high (architectural) costs.
This has hopped sideways into a philosophical design discussion and
perhaps
doesn't belong on this list (mea cupla...)
-Jas
On Mar 26, 2009, at 8:11 PM, [email protected] wrote:
Hello Jeff:
[I deleted a half-typed-rant on this subject (and the related, growing
trend to think "virtualizing solves all my problems") before posting
it... on the theory that I was just being old and crotchety....
suffice it to say that if you consider what is going to happen the
day you have a billion requests pending and you need to switch out
you interpreter/hardware/shared-libs/OS/whatever to one
that can't unpickle them anymore
because you aren't really sure of their data structure... (or,
heaven forbid, there is a subtle bug in your unpickle-and-upgrade
code!). well...]
This topic has come up before. I would prefer to actually run tests
to see what the problems are? I need to look at pickling more in
depth. Maybe it would help if I read up on hot-swapping. I wonder if
modulisation/layering and having an interpreter dampen the effects
of a change?
Currently my approach would be simple. Do a sanity check on the
pickled programme. If you can't properly depickle and continue,
either the old application or the new application, wakes up the
tasklets, tells them something bad has happened, clean-up and
terminate. Sometimes unavoidable bad things happen and cannot be
mitigated.
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
