Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

does thread.kill not kill? (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: UDPSocket
Next thread: Certain ActiveX Controls no longer compile?


Re: File Suggestions?   -   Rubber Chicken Software Co.
  does thread.kill not kill?   -   Peter K. Stys
   Re: does thread.kill not kill?   -   Craig A. Finseth
    RE: does thread.kill not kill?   -   Tim Hare
     Re: does thread.kill not kill?   -   Michael Diehr
   Re: does thread.kill not kill?   -   Peter K. Stys
   Re: does thread.kill not kill?   -   Thomas Tempelmann
   Re: does thread.kill not kill?   -   Peter K. Stys
   Re: does thread.kill not kill?   -   Norman Palardy
   Re: does thread.kill not kill?   -   Peter K. Stys
   Re: does thread.kill not kill?   -   Andy Dent
   Re: does thread.kill not kill?   -   Peter K. Stys
   Re: does thread.kill not kill?   -   Norman Palardy

does thread.kill not kill?
Date: 22.04.09 20:29 (Wed, 22 Apr 2009 13:29:42 -0600)
From: Peter K. Stys
I have these lines:
if self.RBthread_autosat.State = thread.Running then
self.RBthread_autosat.kill
' init some thread properties
self.RBthread_autosat.chNum = chNum
' run it
self.RBthread_autosat.run

The first line checks to make sure self.RBthread_autosat is not already
running from a previous call to this method.
I frequently get crashes with a ThreadAlreadyRunningException at the last
line, when I attempt to run this thread.

How can this be? Should the first line not ensure that this thread is never
running before running again?

RB09r2, Max OS X

P.

Re: does thread.kill not kill?
Date: 22.04.09 20:48 (Wed, 22 Apr 2009 14:48:39 -0500 (CDT))
From: Craig A. Finseth
I have these lines:
if self.RBthread_autosat.State = thread.Running then
self.RBthread_autosat.kill
' init some thread properties
self.RBthread_autosat.chNum = chNum
' run it
self.RBthread_autosat.run

The first line checks to make sure self.RBthread_autosat is not already
running from a previous call to this method.
I frequently get crashes with a ThreadAlreadyRunningException at the last
line, when I attempt to run this thread.

How can this be? Should the first line not ensure that this thread is never
running before running again?

I suspect that the first line starts the process of killing the thread
(which may take some time) and returns immediately.

Normally, when killing any sort of sub-process, you do:

kill the sub-process
while (sub-process is still running and not too much time has passed) {
wait
}
if (sub-process is still waiting) {
...action to take when you can't kill it for some reason...
}
else {
...success!...
}

Craig

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

RE: does thread.kill not kill?
Date: 22.04.09 22:17 (Wed, 22 Apr 2009 14:17:48 -0700)
From: Tim Hare


> -----Original Message-----
> From: <email address removed>
> [mailto:<email address removed>]On Behalf Of Craig
> A. Finseth
> Sent: Wednesday, April 22, 2009 12:49 PM
> To: <email address removed>
> Cc: <email address removed>
> Subject: Re: does thread.kill not kill?
>
> I have these lines:
> if self.RBthread_autosat.State = thread.Running then
> self.RBthread_autosat.kill
> ' init some thread properties
> self.RBthread_autosat.chNum = chNum
> ' run it
> self.RBthread_autosat.run
>
> The first line checks to make sure self.RBthread_autosat is not already
> running from a previous call to this method.
> I frequently get crashes with a ThreadAlreadyRunningException
> at the last
> line, when I attempt to run this thread.
>
> How can this be? Should the first line not ensure that this
> thread is never
> running before running again?


> I suspect that the first line starts the process of killing the thread
> (which may take some time) and returns immediately.
>
> Normally, when killing any sort of sub-process, you do:
>
> kill the sub-process
> while (sub-process is still running and not too much time
> has passed) {
> wait
> }
> if (sub-process is still waiting) {
> ...action to take when you can't kill it for some reason...
> }
> else {
> ...success!...
> }
>
> Craig

I suspect Craig is correct. Also, you should probably test for

State<>Thread.NotRunning

The thread could be sleeping or waiting, and you would get an AlreadyRunning
exception.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 22.04.09 22:58 (Wed, 22 Apr 2009 14:58:47 -0700)
From: Michael Diehr
I believe that thread.kill is effective "immediately" in one sense --
the thread.run command will not execute further. However I think that
the thread state variables are not updated until the next context
switch, which can give the appearance that the thread didn't die
immediately. (I may be wrong about this, but this is what it seems to
be).

In other words, given:

ThreadA.Run
statement1
thread.yield <--- execution was here
statement2

Window1.pushbutton1
threadA.kill
system.log threadA.state
app.yieldcurrentThread
system.log threadA.state

I'm pretty sure that statement2 will never happen, however the state
variable won't be updated until the currently executing thread yields
time.

My theory on this is that "thread.kill" basically tells the thread
scheduler "do not execute this thread again" but doesn't immediately
mark it as dead, until the thread scheduler actually tries to give
time to the (marked for death) thread.



On Apr 22, 2009, at 2:17 PM, Tim Hare wrote:

>
>> -----Original Message-----
>> From: <email address removed>
>> [mailto:<email address removed>]On Behalf Of
>> Craig
>> A. Finseth
>> Sent: Wednesday, April 22, 2009 12:49 PM
>> To: <email address removed>
>> Cc: <email address removed>
>> Subject: Re: does thread.kill not kill?
>>
>> I have these lines:
>> if self.RBthread_autosat.State = thread.Running then
>> self.RBthread_autosat.kill
>> ' init some thread properties
>> self.RBthread_autosat.chNum = chNum
>> ' run it
>> self.RBthread_autosat.run
>>
>> The first line checks to make sure self.RBthread_autosat is not
>> already
>> running from a previous call to this method.
>> I frequently get crashes with a ThreadAlreadyRunningException
>> at the last
>> line, when I attempt to run this thread.
>>
>> How can this be? Should the first line not ensure that this
>> thread is never
>> running before running again?
>
>> I suspect that the first line starts the process of killing the
>> thread
>> (which may take some time) and returns immediately.
>>
>> Normally, when killing any sort of sub-process, you do:
>>
>> kill the sub-process
>> while (sub-process is still running and not too much time
>> has passed) {
>> wait
>> }
>> if (sub-process is still waiting) {
>> ...action to take when you can't kill it for some reason...
>> }
>> else {
>> ...success!...
>> }
>>
>> Craig
>
> I suspect Craig is correct. Also, you should probably test for
>
> State<>Thread.NotRunning
>
> The thread could be sleeping or waiting, and you would get an
> AlreadyRunning
> exception.
>
> Tim
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 22.04.09 22:47 (Wed, 22 Apr 2009 15:47:31 -0600)
From: Peter K. Stys
Thx Craig,
this is maddening, this new way still throws a threadRunning exception at
the .run stmnt:

if self.RBthread_autosat.State = thread.Running then ' is it
running?
self.RBthread_autosat.kill ' then kill it
while self.RBthread_autosat.State = thread.Running ' wait til
it's good and dead
app.YieldToNextThread
wend
end if
self.RBthread_autosat.chNum = chNum
self.RBthread_autosat.run ' still exception: how can this be?

On Wed, Apr 22, 2009 at 1:48 PM, Craig A. Finseth <<email address removed>> wrote:

> I have these lines:
> if self.RBthread_autosat.State = thread.Running then
> self.RBthread_autosat.kill
> ' init some thread properties
> self.RBthread_autosat.chNum = chNum
> ' run it
> self.RBthread_autosat.run
>
> The first line checks to make sure self.RBthread_autosat is not already
> running from a previous call to this method.
> I frequently get crashes with a ThreadAlreadyRunningException at the last
> line, when I attempt to run this thread.
>
> How can this be? Should the first line not ensure that this thread is
> never
> running before running again?
>
> I suspect that the first line starts the process of killing the thread
> (which may take some time) and returns immediately.
>
> Normally, when killing any sort of sub-process, you do:
>
> kill the sub-process
> while (sub-process is still running and not too much time has
> passed) {
> wait
> }
> if (sub-process is still waiting) {
> ...action to take when you can't kill it for some reason...
> }
> else {
> ...success!...
> }
>
> Craig
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 22.04.09 23:05 (Thu, 23 Apr 2009 00:05:59 +0200)
From: Thomas Tempelmann
On Wed, Apr 22, 2009 at 23:47, Peter K. Stys <<email address removed>> wrote:
>
>        if self.RBthread_autosat.State = thread.Running then
>          self.RBthread_autosat.kill   ' then kill it
>          while self.RBthread_autosat.State = thread.Running
>            app.YieldToNextThread
>          wend
>        end if

your while loop does wait for the thread not being "running", but
there may be other states before it's ready to run anew again. so, you
may want to wait for that state.

--
Thomas Tempelmann, http://

Re: does thread.kill not kill?
Date: 22.04.09 23:36 (Wed, 22 Apr 2009 16:36:43 -0600)
From: Peter K. Stys
testing with, as suggested by Tim:
while self.RBthread_autosat.State <> thread.NotRunning
app.YieldToNextThread
wend

did not work either, same exception.

It gets more interesting. In a stripped-down project, where I run a long RB
thread, test for thread.Running, kill it, re-run again, this works as
expected.
Turns out my autosat thread calls a long plugin fn written in C.
So I tested the same stripped down plugin, which now calls a long plugin fn
(fill a 1GB pointer with data). The thread spawning btn is simply this:

self.StaticText1.text = "Start thread..."
self.t.run

and self.t.run event is simply this:

j = fastFillMemblock (self.parentWindow.m, 127, self.parentWindow.m.Size,
0) ' fastFillMemblock is my fast memblock filler written in C
self.parentWindow.StaticText1.Text = "Done"

What is very curious, is when I spawn this self.t thread from the main
window, the GUI (and by extension I assume the main thread) is locked
(the "Start thread..." msg is never displayed, menubar is inactive, etc..)
until my plugin fn finishes, even tho Activity Monitor clearly shows 2
threads running.

I would've thought that the secondary thread self.t would not lock the main
thread, or do cooperative threads need to explicitly make a periodic system
calls to yield time to the scheduler (if so, what is that call from a
plugin?). Long threads written in pure RB automatically make such periodic
calls? This could be part of the anomaly I'm seeing (my plugin is not
dancing nicely with the thread scheduling, yielding, etc...)

P.

On Wed, Apr 22, 2009 at 4:05 PM, Thomas Tempelmann <<email address removed>>wrote:

> On Wed, Apr 22, 2009 at 23:47, Peter K. Stys <<email address removed>> wrote:
> >
> > if self.RBthread_autosat.State = thread.Running then
> > self.RBthread_autosat.kill ' then kill it
> > while self.RBthread_autosat.State = thread.Running
> > app.YieldToNextThread
> > wend
> > end if
>
> your while loop does wait for the thread not being "running", but
> there may be other states before it's ready to run anew again. so, you
> may want to wait for that state.
>
> --
> Thomas Tempelmann, http://www.tempel.org/
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 23.04.09 00:15 (Wed, 22 Apr 2009 17:15:12 -0600)
From: Norman Palardy

On 22-Apr-09, at 4:36 PM, Peter K. Stys wrote:

> What is very curious, is when I spawn this self.t thread from the main
> window, the GUI (and by extension I assume the main thread) is locked
> (the "Start thread..." msg is never displayed, menubar is inactive,
> etc..)
> until my plugin fn finishes, even tho Activity Monitor clearly shows 2
> threads running.

Not so curious if your plugin in C does no yield time back to the RB IDE

> I would've thought that the secondary thread self.t would not lock
> the main
> thread, or do cooperative threads need to explicitly make a periodic
> system
> calls to yield time to the scheduler (if so, what is that call from a
> plugin?). Long threads written in pure RB automatically make such
> periodic
> calls? This could be part of the anomaly I'm seeing (my plugin is not
> dancing nicely with the thread scheduling, yielding, etc...)

Cooperative threads need to cooperate and yield time :)

Long threads written in rb do automagically make such calls
Ones written in C do not

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 23.04.09 00:28 (Wed, 22 Apr 2009 17:28:49 -0600)
From: Peter K. Stys
OK so that makes sense, can anyone tell me what the correct OS call would be
from a plugin, to yield time cooperatively?

On Wed, Apr 22, 2009 at 5:15 PM, Norman Palardy <
<email address removed>> wrote:

>
> On 22-Apr-09, at 4:36 PM, Peter K. Stys wrote:
>
> What is very curious, is when I spawn this self.t thread from the main
>> window, the GUI (and by extension I assume the main thread) is locked
>> (the "Start thread..." msg is never displayed, menubar is inactive, etc..)
>> until my plugin fn finishes, even tho Activity Monitor clearly shows 2
>> threads running.
>>
> Not so curious if your plugin in C does no yield time back to the RB IDE
>
> I would've thought that the secondary thread self.t would not lock the
>> main
>> thread, or do cooperative threads need to explicitly make a periodic
>> system
>> calls to yield time to the scheduler (if so, what is that call from a
>> plugin?). Long threads written in pure RB automatically make such
>> periodic
>> calls? This could be part of the anomaly I'm seeing (my plugin is not
>> dancing nicely with the thread scheduling, yielding, etc...)
>>
> Cooperative threads need to cooperate and yield time :)
>
> Long threads written in rb do automagically make such calls
> Ones written in C do not
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 23.04.09 00:49 (Thu, 23 Apr 2009 07:49:17 +0800)
From: Andy Dent

On 04/23/2009, at 7:28 AM, Peter K. Stys wrote:

> OK so that makes sense, can anyone tell me what the correct OS call
> would be
> from a plugin, to yield time cooperatively?

It is not an OS call - RB threads are not OS-based and are purely
within RB land.

REALYieldToRB
This function yields time back to the REALbasic runtime so that it can
do periodic processing, such as cooperative thread context switching.
You should call this function any time you do a long task in a plugin.
However, it is not advisable to call this function too frequently in a
loop as it can degrade the performance of your plugin.

Andy Dent
Freelance Designer-Developer - C++, C#, Objective-C, Python, REALbasic

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 23.04.09 00:51 (Wed, 22 Apr 2009 17:51:48 -0600)
From: Peter K. Stys
Thx Andy,P.

On Wed, Apr 22, 2009 at 5:49 PM, Andy Dent <<email address removed>> wrote:

>
> On 04/23/2009, at 7:28 AM, Peter K. Stys wrote:
>
> OK so that makes sense, can anyone tell me what the correct OS call would
>> be
>> from a plugin, to yield time cooperatively?
>>
> It is not an OS call - RB threads are not OS-based and are purely within RB
> land.
>
> REALYieldToRB
> This function yields time back to the REALbasic runtime so that it can do
> periodic processing, such as cooperative thread context switching. You
> should call this function any time you do a long task in a plugin. However,
> it is not advisable to call this function too frequently in a loop as it can
> degrade the performance of your plugin.
>
> Andy Dent
> Freelance Designer-Developer - C++, C#, Objective-C, Python, REALbasic
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: does thread.kill not kill?
Date: 23.04.09 00:54 (Wed, 22 Apr 2009 17:54:57 -0600)
From: Norman Palardy

On 22-Apr-09, at 5:28 PM, Peter K. Stys wrote:

> OK so that makes sense, can anyone tell me what the correct OS call
> would be
> from a plugin, to yield time cooperatively?

It's not an OS call
There's a yield call in the RB plugin SDK that yields time back to RB

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>