Friday, October 17, 2003, 2:11:47 PM, Robert wrote:
> On Tue, 14 Oct 2003 19:18:36 -0400, Brian Parkinson > <[EMAIL PROTECTED]> wrote: >> I want to set up (say) a Rugby server, which will accept client >> connections and process them. I'd like each connection to be handled in >> its own thread (let's keep it simple and leave thread pools, resource >> utilization and the like out of this) as I need each client's response >> to be in reasonable time (pretend the processing involves I/O or >> something). I'm kinda astonished that I can't do this in Rebol proper. >> Unless I'm missing something real obvious, the only way that I can do >> this is to rely on code that implements a cooperative multitasking >> queue (a la Rugby) or roll my own (!). > Hi, don't bee fooled by all this multi-threading hype. For example, > have a look at www.xitami.com and theire LRWP protocol. This is done > using a cooperative multi-tasking. Very cool and fast, and it can be > coupled with Rebol quite easy. The problem I see w/ coop multi-tasking (and I've implemented two coop mt server frameworks in REBOL) is that it's a viral, an all-or-nothing approach. If I have e.g. disk IO, I've to impl a simple file IO in a coop way, i.e. decompositing it into a state machine w/ small tasks that preferrably don't block. If I've some computing intensive algorithm, once more, I've to state it in a coop way. And I (my very personal opinion based on my experiences with that kind of stuff in REBOL) find that decomposition rather boring and the result quite hard to maintain. Imho, first class continuations would help in this situation, but that's another topic. So, when you control the whole application, it's at least possible to completely adhere to a coop oriented programming approach. Once I want to cleanly integrate with external apps or other libraries, yeah, problems may arise - who guarantees that the library of my choice does not use blocking IO, for example? I'm in no way an expert in the theoretical issues surrounding this topic, nor am I a REBOL guru. So it may well be that I've missed some nifty ways to write something that won't require complete changes in all my coding habits. So - questions, corrections and suggestions are welcome :) -- Best regards, Andreas -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
