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

Reply via email to