FAQ
Cover
This is the archive Discourse for the Processing (ALPHA) software.
Please visit the new Processing forum for current information.

   Processing 1.0 _ALPHA_
   Programming Questions & Help
   Syntax
(Moderators: fry, REAS)
   threads
« Previous topic | Next topic »

Pages: 1 
   Author  Topic: threads  (Read 1224 times)
justo


threads
« on: Oct 29th, 2003, 12:33am »

is implementing threads in processing difficult? i've only done it once in a java project, so i wonder if it gets confusing within the java framework.
 
to give you some context, i have some automated drawing going on in a back-back-buffer with a pretty low priority (it could happen at 10 frames per second), but the interface shouldnt be slowed at all...it needs to be interactive in real time.
 
thoughts and comments are much appreciated.
« Last Edit: Oct 29th, 2003, 12:33am by justo »  
benelek

35160983516098 WWW Email
Re: threads
« Reply #1 on: Oct 29th, 2003, 5:44am »

hi justo, here's a small piece of code i put together a while ago to teach myself threading in p5:
 
Code:
//this is a sketch for automatic self-adjusting of threads' speeds.
//bnlk.
 
class threader implements Runnable {
  int floorTime=5;
  int delayTime=floorTime;
  threader() {
  }
   
  public void run() {
    while(true) {
 long startMillis=max(1,millis());
 
 //do some task:
 for(int i=0; i<1000; i++) {
   fill((int)random(255),0,0);
   rect(random(100),random(100),random(100,200),random(100,200));
 }
 
 long finishMillis=max(2,millis());
 delayTime=max(int(finishMillis-startMillis)+5,floorTime);
 delay(delayTime);
 repaint();
    }
  }
 
}
 
threader object1;
Thread wrapper;
 
void setup() {
  size(200,200);
}
void draw() {
  object1=new threader();
  wrapper=new Thread(object1);
  wrapper.start();
}
 
justo


Re: threads
« Reply #2 on: Oct 29th, 2003, 5:58pm »

it works! thanks for your help. perhaps i'll post the project when i'm finished. now, haha, one minor thing...the thread never stops, even when i close the applet (i found this out when a println statement kept printing).
 
is there a non-deprecated way of stoping the thread? does anyone know if i can override processing's stop method, call super.stop() just in case and then set it to null?
 
benelek

35160983516098 WWW Email
Re: threads
« Reply #3 on: Oct 31st, 2003, 2:07am »

that's... uh... strange. are you sure you're not just experiencing a delay in the exit of the sketch? i mean, if you leave it for a while, does it *eventually* stop on its own?
 
senior

89237688923768 WWW
Re: threads
« Reply #4 on: Oct 31st, 2003, 8:43pm »

I'm having issues with the threads not quitting, too.
 
Also: is delay() a p5 function? Because if I try to use it in java mode, I get an error saying: No method named "delay" was found in type "Threader".
 
benelek

35160983516098 WWW Email
Re: threads
« Reply #5 on: Nov 1st, 2003, 10:46am »

i'm not sure if it's also a pure java thing, but it's definately a p5 method:  
http://proce55ing.net/reference/delay_.html
 
as for the thread not stopping, this is also happening when i test the code now. i wrote it a while ago, so perhaps something's changed in p5. does anybody know if there's something i'm supposed to do to tell p5 to kill the thread when the sketch is stopped?
 
Martin

122417302122417302martingomez_listsmg1ph WWW Email
Re: threads
« Reply #6 on: Nov 2nd, 2003, 2:27pm »

you might be interested to see how brainfuck was done.
 
fry


WWW
Re: threads
« Reply #7 on: Nov 3rd, 2003, 5:21pm »

supposedly, the stop() method can be overridden, and used to catch things like this. however, i haven't had much luck with browsers calling this function properly. i'll add this to the list of things to be looked into, since it's an obvious problem that needs  a solution (which is currently non-obvious).
 
justo


Re: threads
« Reply #8 on: Nov 5th, 2003, 9:16am »

ok, i added this to my program:
 
public void stop() {
  super.stop();
  myThread = null;
  rusty.run = false;
}
 
(rusty being the object thats running in the thread)
 
i tried it first without the boolean 'run' value in rusty, which now controls the loop within rusty's run() method:
 
while (true) {...   //before
while (run) {...    //now
 
the problem was that the while loop would keep executing...garbage collection wouldnt pick it up because it was rusty that was running, not myThread.
 
threads are supposed to only run until their run() method returns, so this solution should be enough to end the thread. i dont know about the reliablility of stop() in browsers, but it's definitely called when viewing applets within processing, and thats what has really been bothering me...huge slow downs when i've run the applet just a few times.
 
thanks for the help everyone.
 
benelek

35160983516098 WWW Email
Re: threads
« Reply #9 on: Nov 6th, 2003, 2:26am »

that sounds like a good solution - Ariel, are you the one updating the Technotes page? would you mind putting a link to this thread?
 
arielm

WWW
Re: threads
« Reply #10 on: Nov 6th, 2003, 2:53am »

actually, the plan was that a web-engine would be ready very soon to take care of that...
 
what i propose:
- bookmark this thread (as well as other ones that you find relevant)
- decide in which technotes section it should go
- find a proper title for the entry
 
then, when appropriate, it will be possible to use all this useful info...
« Last Edit: Nov 6th, 2003, 2:58am by arielm »  

Ariel Malka | www.chronotext.org
fry


WWW
Re: threads
« Reply #11 on: Jul 15th, 2004, 4:48pm »

we'll add an example for megabucket that uses threads the "proper" way so hopefully that'll clear up some confusion.
 
Pages: 1 

« Previous topic | Next topic »