Re: "Random" delays in execution

["Max van Rooij \(van Rooij Electronics Design & Software Engineering\)" <mvrooij@...>]

Dear all,

Some more details:


Roberto asked: ".... And the pauses seem too long (2.5 seconds, is that
right?)...."

Yes, the 2.5 sec is true! Even longer if I create a larger 2D array.

Jerome remarked: "The coroutine itself takes some memory. So each time
you terminate a thread you are releasing that memory, but it will stay
allocated until a collection cycle. The memory includes the thread
itself, its main closure, any local/upvalue referenced by that closure,
and the thread global environment if it's not shared....."

The userdata is 280 bytes in size (according to sizeof()); it has a
registered __gc method.

I create a Lua _state_ and run the following Lua script:

-- delay test script

NCOLS = 20
NROWS = 10

cel = {} -- create a table
for cols=1, NCOLS do
	cel[cols] = {} -- new table inside table
	for rows=1, NROWS do
		cel[cols][rows] = roi.create(1 + cols*15, 1 + rows*15,
15, 15) --roi is a C struct, using malloc()
		--cel[cols][rows] = cols*rows --same thing, but uses far
less memory and far less GC time
	end
end

Then I create a _thread_ running the follwing Lua script:

-- delay test script

-- request image and wait for it to be ready
repeat
	system.imagerequest()
	coroutine.yield()
until system.imageavailable() == 1 -- wait for new image

system.displayrefresh(1) -- send new image and it's info to display

That's all. Lua_resume() gives either LUA_YIELD as result or 0 (end of
script). If it returns 0 I create a new tread, load the 2nd script and
run it again. If yielded, I simply call lua_resume again.

I have a hunch that Jerome is on the right track, by stating that each
new thread gets a copy of the cel table which gets marked for GC after
threads' end. If this is the case, then how to prevent it?

Max