On Fri, 24 Oct 2003, Peter Haworth wrote:
> 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?
The latter. :)
We avoid extra memory usage in a destroy-time traversal for freezing the
same way we avoid it for DOD--make sure that the memory we need is
available to the traversal system in advance.
This is one of the reasons I wanted to use the next_for_gc pointer in the
PMCs to build the traversal chain, as the memory's already allocated and
we wouldn't need to expand the PMCs any.
It is certainly possible that the mechanism the user code chooses to use
to freeze will exhaust some resource--disk space, RAM, bandwidth
allotment, Universal electron supply, or something of the sort. That's
fine, it's user code and is allowed to fail like that. We, on the other
hand, have to make sure that we don't fail as part of the traversal.
It's a pain, sure, but there are a number of applications where worst-case
behaviour guarantees are required. I don't know that Parrot will ever be
seriously used in an embedded application or semi-embedded application
(like a Palm device) but enough folks have made noise about it that I'm
trying not to make it impossible.
I do realize that we're making some of our normal-case resource usages
higher in exchange for a better guaranteed worst case, but at the moment I
think that's worthwhile.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
