[Solved] How to kill thread on any error?

[4aiman]

So, I've started a thread, put a call of inexistent function and caught a error from that thread in the main app.
The problem is thread doesn't stop on error, but continue to throw errors.

Is there a way to reliably stop server if anything throws error within it?

[Luke100000]

If the thread crashes or finishes, the thread is dead. If you call thread:start() again it restarts.
So, the thread should not continue running, unless you restart it somewhere in the main app.

[4aiman]

That is what I have been told multiple times...
Yet, thread:getError() *still* returns the last error message from a thread forever.

Code: Select all

if not data.updated then				   				             -- need that flag to bypass updates - simple and 	hackable
	print("[Server]:","Client ".. data.nick .." needs to be updated")
	local testport = 1
	while app.data_ports[testport] do                            -- find a free channel, remember to free it @from a thread@!!!
		testport = testport+1
	end

	local dataport = testport+app.data_port_start                -- actual port for a thread server to listen to
	local offload = {port=dataport, address=app.data_address}    -- client AND server only need to know address:port info. Those may differ for various clients. Probably.
	local thread = love.thread.newThread("thread.lua")				 -- making a thread
	local chan   = love.thread.getChannel(tostring(thread))      -- making up an exclusive channel

	app.data_ports[testport] = true                              -- marking dataport as busy/taken
	app.data_threads[#app.data_threads+1]  = {t=thread, c=chan}  -- storing thread and channel pointers locally

	print("[Server]:","Offloading update to a thread ".. app.data_address ..":" .. dataport)
	thread:start(chan, #app.data_threads)                        -- starting the thread
	chan:push(offload)                                           -- sending address:port to a thread

	client:send("You need updates. Probably?",offload)				 -- sending address:port to client
	return
end

Note the

Code: Select all

app.data_threads[#app.data_threads+1]

line.


Now, in love.update I have this

Code: Select all

for i,ti in pairs(app.data_threads) do
	 t = ti.t
	 c = ti.c
	 local err = t:getError()
	 if err then
		 print("[Error (thread #".. i..")]:",err)
	 end
end

Should I put some clearly faulty invocation in a thread.lua (like "foo()", which doesn't exist anywhere) I'll get this:

Code: Select all

[Error (thread #1)]:	thread.lua:33: attempt to call global 'foo' (a nil value)

message repeated over and over.
Either getError() recreates a thread or I don't know what to think...

How am I able to index local t if it is dead?
Certainly, i can set app.data_threads[ i ] to nil if there's a error, but that doesn't mean I'm closing/deleting a thread.

I can swear there's no any other place aside from the one I shown where I create a thread explicitly.
Are there any methods which do that implicitly?

[MasterLee]

Try
https://love2d.org/wiki/love.threaderror

[bartbes]

Yet, thread:getError() *still* returns the last error message from a thread forever.

That's because it will always have exited with that error. getError simply returns the error, it doesn't "remove" it.

[raidho36]

Well maybe behavior should be changed to clear the error, if that is what expected of it. It's not like there is a good reason to keep last error forever.

[MasterLee]

Or you could make an parameter to choose if the error should be cleaned

[slime]

Thread:getError only returns an error until the Thread is successfully restarted.

[4aiman]

Wow. Thanks everyone!
The thing which lead me into believeing thread's not killed was the ability to index that thread variable.
Kinda expected it to throw "attempt to index a nil value" error.

As for changing behavior, I guess if wiki said the error will be returned forever I'd just ignored it.
Oris there a way to remove that error message from the queue?

[bartbes]

Wow. Thanks everyone!
The thing which lead me into believeing thread's not killed was the ability to index that thread variable.
Kinda expected it to throw "attempt to index a nil value" error.

Apart from it being nigh impossible, it'd be a bit weird if your environment were to suddenly change if the thread stopped, wouldn't it? And how would you get the error?

As for changing behavior, I guess if wiki said the error will be returned forever I'd just ignored it.
Oris there a way to remove that error message from the queue?

But it isn't a queue. If there is an (uncaught) error, the thread terminates, so it can't create a second error.