<OT>Can we coroutine email threads?</OT>

I can think of several ways of reducing problems relating to running out of the remapBuffer.

First, don't do that. Allocating objects in primitives other than primitiveNew and primitiveNewWithArg is unwise. It circumvents any nicely tuned policy you might have in the image. It's better to allocate objects and pass them to the prim whenever possible; this allows you to write code to handle problems more easily. It keeps the prims simpler. It reduces the number of dependents on object memory protocol which is already far too high.

Next, if you have to allocate objects in prims, make it possible to fail the prim when an allocate fails. Have image code handle the problem and retry the prim. It would be nice if the prims could return failure codes instead of simply "Ugh!" I have code that provided this for an older version and it wouldbe easy to bring up to date. It might help with some of the error cases involved in directory checking as well....

Lastly, if one is really wedded to the current ritual abuse of the object memory, make the remapBuffer a linked list (or something of the sort - steal some of the DisplayBitmap, anything) so it can be arbitrarily long; there will still be problems if one is really short on memory but then you're in real trouble anyway by that stage.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- She wears a pony tail to cover up the valve stem.