Alexandre

I'm looking for a way to stop a "process" or a "thread". i have a method in mxj which is called when i change the value of a number box in max, and this method executes a drawing-thread to draw something which can, sometimes, be slow. (if a change the value very fast in max, the method doesn't have time to compute everytime)

So, i'd like, that, when the method is called, it tests to see if the drawing-thread is already running (from a previous method call), and if it's the case, that it delete the thread and restart it. i'm not sure how to do that. first i managed to create a thread inside my method, with :

public void redraw_because_value_changed( int value_from_max ) {

This works fine, but will create many threads if the drawing is slow while i change the value in max, causing slow down. But then i tried to name the thread, and delete it before restarting a new one, and first, this works a little, but when i change my value very fast in max5, it crashes. :

( curveThread = new Thread() { public void run() {

I not sure to understand well how to manage this. In the "flies.java" example, there's an other example on managing threads, but i can't figure out how it works plus the need in "flies" is different.

I'm looking for a way to stop a "process" or a "thread". i have a method in mxj which is called when i change the value of a number box in max, and this method executes a drawing-thread to draw something which can, sometimes, be slow. (if a change the value very fast in max, the method doesn't have time to compute everytime) 

public void redraw_because_value_changed( int value_from_max ) {
    ...
    ( new Thread() { public void run() {
         ...// the drawing stuff ...
    }}).start();
}

public void redraw_because_value_changed( int value_from_max ) {
    ...
    curveThread = null ;
    ( curveThread =  new Thread() { public void run() {
          ...// the drawing stuff ...
    }}).start();
}

newbie-in-threads-question

to me this problem is more related to general threading issues than to 

mxj programming. I think the Sun Tutorial on concurrency,

http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

would be a good starting point for you. In my opinion, it will be far 

enough at this point for you to read it just until the end of the first 

> I'm looking for a way to stop a "process" or a "thread". i have a method in mxj which is called when i change the value of a number box in max, and this method executes a drawing-thread to draw something which can, sometimes, be slow. (if a change the value very fast in max, the method doesn't have time to compute everytime) 

> So, i'd like, that, when the method is called, it tests to see if the drawing-thread is already running (from a previous method call), and if it's the case, that it delete the thread and restart it. i'm not sure how to do that. first i managed to create a thread inside my method, with :

> public void redraw_because_value_changed( int value_from_max ) {

> This works fine, but will create many threads if the drawing is slow while i change the value in max, causing slow down. But then i tried to name the thread, and delete it before restarting a new one, and first, this works a little, but when i change my value very fast in max5, it crashes. :

> ( curveThread = new Thread() { public void run() {

> I not sure to understand well how to manage this. In the "flies.java" example, there's an other example on managing threads, but i can't figure out how it works plus the need in "flies" is different.

to me this problem is more related to general threading issues than to 
mxj programming. I think the Sun Tutorial on concurrency,

would be a good starting point for you. In my opinion, it will be far 
enough at this point for you to read it just until the end of the first 
big paragraph (called Thread Objects).

____________________
Siska Ádám
+36 (70) 207-63-85
http://www.sadam.hu/

Alexandre wrote:
> Hi,
>
> I'm looking for a way to stop a "process" or a "thread". i have a method in mxj which is called when i change the value of a number box in max, and this method executes a drawing-thread to draw something which can, sometimes, be slow. (if a change the value very fast in max, the method doesn't have time to compute everytime) 
>
> So, i'd like, that, when the method is called, it tests to see if the drawing-thread is already running (from a previous method call), and if it's the case, that it delete the thread and restart it. i'm not sure how to do that. first i managed to create a thread inside my method, with :
>
> public void redraw_because_value_changed( int value_from_max ) {
>     ...
>     ( new Thread() { public void run() {
>          ...// the drawing stuff ...
>     }}).start();
> }
>
> This works fine, but will create many threads if the drawing is slow while i change the value in max, causing slow down. But then i tried to name the thread, and delete it before restarting a new one, and first, this works a little, but when i change my value very fast in max5, it crashes. :
>
>
> Thread curveThread; 
>
> public void redraw_because_value_changed( int value_from_max ) {
>     ...
>     curveThread = null ;
>     ( curveThread =  new Thread() { public void run() {
>           ...// the drawing stuff ...
>     }}).start();
> }
>
>
> I not sure to understand well how to manage this. In the "flies.java" example, there's an other example on managing threads, but i can't figure out how it works plus the need in "flies" is different.
>
>
> Thanks a lot for any help.
>
> Alexandre.
>
>
>

To achieve good performance, you should probably avoid deleting and recreating the same kind of object when possible. In your case, it may make more sense to set a volatile variable in the Thread like "runAgain", which the thread will check after it's done drawing and loop back to the beginning of the draw routine if runAgain==true. Or maybe you can interrupt() your Thread and then restart it, instead of delete/recreate.

http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

Also, on the Max side, you should consider using a speedlim object between your number box and mxj.

In fact, looking completly at your links, it's looking like there no way to stop a thread without testing inside itself, with methods like "Thread.interrupted" or "catch (InterruptedException e)":

"What if a thread goes a long time without invoking a method that throws InterruptedException? Then it must periodically invoke Thread.interrupted, which returns true if an interrupt has been received." ( 

http://java.sun.com/docs/books/tutorial/essential/concurrency/interrupt.html

mmh.. This stop() method from "java.lang.Thread" , is now deprecated for complicated reasons. So, if i have to test from inside my loops, to continue or to "break", i just can use effectivly a kind of "runAgain" booleen, defined in the class (or "volatile"?.. an other concept to learn for me), which can ask the thread to stop. (when the booleen is tested at each end of my heavy-drawing-loop) Without any need to bother myself with new methods with which i'm not confortable with.

But, is it really sure that there no way to stop a thread without introducing testing stuff periodically in the thread itself ?

Well, i might post this question to a java forum, but for now, i just realised that a big part of my drawing time was, actually, the call of com.cycling74.jitter.JitterMatrix.copyBufferedImage : 100 milliseconds!... (for a 1200*700 image)

I posted a new topic for this new problem.

"What if a thread goes a long time without invoking a method that throws InterruptedException? Then it must periodically invoke Thread.interrupted, which returns true if an interrupt has been received."  ( http://java.sun.com/docs/books/tutorial/essential/concurrency/interrupt.html )

Well, i might post this question to a java forum, but for now, i just realised that a big part of my drawing time was, actually, the call of com.cycling74.jitter.JitterMatrix.copyBufferedImage : 100 milliseconds!... (for a 1200*700 image)
I posted a new topic for this new problem.

> But, is it really sure that there no way to stop a thread without

> introducing testing stuff periodically in the thread itself ?

Yes - the reason stop() was deprecated was partly because the only way 

of telling if it's safe to stop a thread is from within.

Alexandre wrote:
> But, is it really sure that there no way to stop a thread without
> introducing testing stuff periodically in the thread itself ?

Yes - the reason stop() was deprecated was partly because the only way 
of telling if it's safe to stop a thread is from within.

On 23 Jun 2008, at 19:10, Alexandre wrote:

> mmh.. This stop() method from "java.lang.Thread" , is now deprecated 

Complicated, but quite important: if you start writing multithreaded 

code you'll have to understand semaphores. In other words, threading 

is subtle and quick to anger. But if you keep it simple and keep a 

> mmh.. This stop() method from "java.lang.Thread" , is now deprecated  
> for complicated reasons.

Complicated, but quite important: if you start writing multithreaded  
code you'll have to understand semaphores. In other words, threading  
is subtle and quick to anger. But if you keep it simple and keep a  
clear head, it's manageable.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


ok i think i understand better now. thanks.

newbie in threads question