Hi Brian, On Wednesday, October 15, 2003, 1:18:36 AM, you wrote:
BP> to be in reasonable time (pretend the processing involves I/O or BP> something). If it's just because of I/O, then you have async I/O (well, partially, but this is expected to be completed soon...), which is far simpler than multithreading. If you have a lot of calculations, instead, some form of multitasking is required. Uniserve uses a pool of REBOL processes to achieve this. Multithreading seems like a nice thing to have, but if you consider all the things that are involved, you realize that most of the times it does more harm than good. This said, one of the reason why Nenad started the R# project (not to be confused with Andrew's R# :), is to create a multithreaded REBOL clone. We'll see how mush trouble this will mean. ;-) BP> Unless I'm missing something real obvious, the only way that I can do BP> this is to rely on code that implements a cooperative multitasking BP> queue (a la Rugby) or roll my own (!). Rolling your own might be much easier than you'd expect. BP> I hate to bring in language wars (as I am quite taken with Rebol, and BP> have been able to do some really cool stuff with this) but a BP> multi-threaded server like this is bread 'n butter in Java (and others). Well, yes, if you pretend to ignore all the synchronization issues. As long as your threads do not share data, there's no difference in using multithreading instead of just launching other processes. Regards, Gabriele. -- Gabriele Santilli <[EMAIL PROTECTED]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/ -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
