It might be possible to send an exception to a thread and kill it that way. In many cases it would be enough if the thread got killed on backjumps/functioncalls/whereever other stuff are checked as well...
/ Mirar
Previous text:
2004-08-11 15:35: Subject: Re: killing threads
On Tue, 10 Aug 2004, Ken wrote:
Hello,
In a multi-threaded app, is it possible to kill a thread through means other than the starting function returning?
No, and the reason is that it is nontrivial to clean up the resources held by the killed thread.
Hmm... I guess it'd be possible to let check_threads_etc() throw an error of severity level THROW_THREAD_KILLED. Feel free to experiment.
I've tried using the kill() function, but all the signals cause the entire app to die.
Thanks for any input!
-Ken
-- Henrik Grubbström grubba@roxen.com Roxen Internet Software AB
/ Brevbäraren
Well, that's where check_threads_etc() gets called anyway.
/ Henrik Grubbström (Lysator)
Previous text:
2004-08-11 15:58: Subject: Re: killing threads
It might be possible to send an exception to a thread and kill it that way. In many cases it would be enough if the thread got killed on backjumps/functioncalls/whereever other stuff are checked as well...
/ Mirar
If you can queue exceptions there it might be enough.
When isn't it enough? When threads wait for system call returns?
/ Mirar
Previous text:
2004-08-11 16:16: Subject: Re: killing threads
Well, that's where check_threads_etc() gets called anyway.
/ Henrik Grubbström (Lysator)
Exactly, and that is probably the most common use, since otherwise you could do with a Pike-level implementation.
/ Henrik Grubbström (Lysator)
Previous text:
2004-08-11 16:28: Subject: Re: killing threads
If you can queue exceptions there it might be enough.
When isn't it enough? When threads wait for system call returns?
/ Mirar
Kan you return from them with signalling the thread?
/ Mirar
Previous text:
2004-08-11 16:31: Subject: Re: killing threads
Exactly, and that is probably the most common use, since otherwise you could do with a Pike-level implementation.
/ Henrik Grubbström (Lysator)
In this case it was to stop pike-level threads from running amok, I believe. In that case just forcing an exception on a thread might work very well, even if it's pike-level and could have other solutions.
/ Mirar
Previous text:
2004-08-11 16:31: Subject: Re: killing threads
Exactly, and that is probably the most common use, since otherwise you could do with a Pike-level implementation.
/ Henrik Grubbström (Lysator)
In the last episode (Aug 11), Mirar @ Pike developers forum said:
In this case it was to stop pike-level threads from running amok, I believe. In that case just forcing an exception on a thread might work very well, even if it's pike-level and could have other solutions.
How about just adding a function that calls pthread_cancel()?
That sounds like it could lead to very interesting memory leaks?
/ Mirar
Previous text:
2004-08-11 17:18: Subject: Re: killing threads
In the last episode (Aug 11), Mirar @ Pike developers forum said:
In this case it was to stop pike-level threads from running amok, I believe. In that case just forcing an exception on a thread might work very well, even if it's pike-level and could have other solutions.
How about just adding a function that calls pthread_cancel()?
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
In the last episode (Aug 11), Mirar @ Pike developers forum said:
That sounds like it could lead to very interesting memory leaks?
You've got a couple choices: You can disable cancels, which really queues then instead of disabling them. A thread can run pthread_testcancel() to check to see if it must exit. That's probably the easist to integrate into pike, since you can choose when to check for cancellation, but won't help if you have a thread stuck in a C loop.
The other option is to leave cancels enabled and use a thread cleanup handler to clean up local resources. You would likely leak any memory allocated by C modules unless they were thread-aware enough to push their own cleanup handlers.
http://docs.sun.com/db/doc/816-0216/6m6ngupgl?a=view http://www.opengroup.org/onlinepubs/009695399/functions/pthread_setcancelsta...
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Mirar ＠ Pike developers forum