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

[REBOL] Re: Multithreading with Rebol

From: rotenca:telvia:it at: 17-Oct-2003 16:50

Hi Andreas,
> 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.
I agree at all. Writing cooperative code without continuations is very hard. A dialect can be used to handle particular cases of continuations in Rebol (i should say "cooperative continuations"). Else the resulting code is a very big FSM, which among the other things, should have a clear idea of time costs of all operations and this is hard to know for a script which should run without any change on every system and with different data input.
> 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 :)
I'm not an expert, but surely with do/next can be emulated a preemptive multitasking environment. The result is probably a very slow program. I think that it is not the Rebol language the best level in which multitasking must be handled. I have also seen at least one program which implements what seems a multitasking dispatcher/scheduler. But the code for this stuff is 1) very long 2) hard to read 3) hard to change 4) sometime slow (i think). So some of the best reasons to use Rebol are totally lost with also simple multitasking emulation. The lack of async i/o on files makes more hard to write this kind of scripts. --- Ciao Romano