Hans Hagen wrote:
Jonathan Sauer wrote:
Well, I experimented a bit and am now a lot wiser. Also, I have confirmation on what I thought all along: My computer's internal harddisk is much too slow:
How to measure the performance of virtual memory:
\directlua0{lua.bytecode[100000000] = function() end}
works ok here (but i have a 4 gig machine); technically it should only allocate one lua state; on the other hand, it may be that a non sparse array is used for the register housekeeping
Yes, and that itself is a temporary measure. Nevertheless, the integer overflow is serious enough to warrant a fix in the next beta (it will be a while before I get to cleaning up the bytecode array).
another overflow can be in the piping data to tex (tex.print) .. if you collect 2 gig data there you may also run into problems
Not so sure. Lua itself would probably have stopped you before that, but I can't test that now as it would take forever on this machine.
IMO it would be sensible to limit the number of bytecode registers to UINT_MAX/sizeof(bytecode) or -- to be platform-independent in the light of 64 bit processors[2] -- (2^32-1)/sizeof(bytecode).
such a limitation is not that meaningful;
In practice it is, as it prevents uncontrolled crashes.
[3] I think, this is the result of the sig-handler LuaTeX installs which displays an error message. But it seems that this message has been overwritten as well.
It is actually the message in the crash handler in the C runtime. Best wishes, Taco