Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] [Threading] continued

From: maximo:meteorstudios at: 29-Jan-2004 17:58

> -----Original Message----- > From: Jason Cunliffe [mailto:[jason--cunliffe--verizon--net]] > Sent: Thursday, January 29, 2004 4:44 PM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: Threading continued > > Can you briefly describe any use-cases where this threading > would make a > difference .
one example for threading useage is that you can crunch information WHILE you are also waiting on a port. this basically allows your server to be up all the time, although he is busy with any matter of processes. when creating a render queue or a transaction-based system, you can tell the system to do things, and he won't do them right away, but you can still send the commands and receive confirmations that your processes have been done. then if you need information, another thread, can lookup the processing queue and verify if there is yet some processing to be done on that item. if there is then it either processes it right away in its own thread, if possible, before returning the new and improved data. this doesn't keep the other thread from continuing to crunch the other items in the list while they are not needed. if you didn't have threads, then you'd have to wait for the current processing to finish before your server even responds to any new request. threading allows your server to be more responsive, altough it also slows down each of those responses as they process simultaneously. As maarteen explained, if threading is implemented virtually, then the cost of tracking/handling the threads means that you remove some processing cycles from each of the threads themselves. HTH! Maarten, I am not an expert, but would it be possible, with the design you have, to throttle some threads, so that the server can allocate more processing where it really needs it? like giving less time to a thread which handles communications and more to another which does heavy number crunching ... or the opposite, if server querry/response is more important than the rate at which your processing queue actually flushes itself? -MAx PS, Maarten, if you DO decide to tackle this threading project... I WILL be checking it out, as I know some uses I'd make of it.