On Tue, 21 Oct 2003 11:39:38 -0400 (EDT), Dan Sugalski wrote: > On Tue, 21 Oct 2003, Juergen Boemmels wrote: > > This is a question of what is allowed at destruction time. You don't > > want to allow memory allocation, but allow freezing. That gets hard, > > because you need at least allocate the STRING where you want to put your > > frozen stream. > > It's more a question of what we we require the engine to do, vs what user > code is allowed to do. A user program is allowed to write code that can > fail at destroy time, however the infrastructure we provide (including, in > this case, freezing--while I don't like it there's no choice) can't fail > that way. It's the reason the DOD and GC systems don't allocate memory (or > didn't--they shouldn't) when they run. The engine's not allowed to have > failure modes in critical sections.
How can you serialise without using any extra memory? Even if you stream the serialised data directly to disk one byte at a time (which could fail just as easily as allocating memory to hold the serialised data in memory), serialisation of anything more complex than a native type is inherently recursive. Either you use up call stack space recursing over the PMCs, or you need an explicitly manage a stack/queue of PMCs not yet serialised. Have I missed some wonder of modern computing, or just something so obvious I can't see it? -- Peter Haworth [EMAIL PROTECTED] "What's so unpleasant about being drunk?" "You ask a glass of water." -- Douglas Adams, HHGTTG