And it will be lengthy again....
> I'm afraid mine too...:)
> > The first thing to realize is that threads are really processes with
> > memory. (And shared memory is the root of all evil.....) This also
> > that mutli-threading for performance is only really working on multiple
> > processor systems.[...]
> I do not agree. Multi-threading works and performs very well on a single
It works well but you are switching between threads which is overhead you
can save if you do it yourself within one process. Unless you have native
threads, SMP, and multiple processors, because you are not switching then.
> > Now I am not
> > saying that you should write your own OS, it's merely a blunt reminder
> > most things can be done in most environments if you really want to
> > at the interpreter level, implemented in REBOL for example).
> In Rebol ? I already thought about doing that, but firstly, i see no way
> it in a premptive mode but only in a cooperative mode (like Win3.1) and
> i'm afraid that it will spend more time switching between your scripts
> them...:) IMHO, the only viable way is to implement it at least at the
interpreter level (in C).
You have non-blocking I/O so you would change all IO to have that as a
default mode, so it is interruptable. Then you'd give a weight to all the
natives and count reductions on the rest in your evaluator and do the
switching after n reductions. Still a lot of work though.
> > Take a look at the rugby console (rugby-console.r) on the REB, for
> > It runs a server while you can type on the console in Core 2.5
> This is just non-blocking I/O ! You're multiplexing between several I/O
> most of their time waiting for something to happen on ports ! When
something finally happens on
> a port, you have to pray that the event processing won't take much time
else you'll block
> all other ports...It can work fine if all requests processing take very
little time, but if
> any request takes several seconds to complete, all others will...wait !
That's true. My point was that you can get to things scheduled as far as I/O
is concerned. If you program efficiently (divide your tasks and have them
pass control back every now and then) this works fine.
> With a single process server, you can answer only one request at the same
time ! You can
> build a high-perf server based on a single thread only if you're spending
most of the
> time multiplexing I/O events and very few time in request processing. That
> well for a web server (building a HTTP response doesn't take much time)
like Zeus or
> MEDUSA, but i'm don't think that an ORB or Application Server can match
NO!! I did middleware ;-) The point is related to the single processor
problem: you are in the end switching between threads and are at most one is
running at the same time. If you program your functions as little state
machines that pass control back after every state and continue on the next
invocation you get the same result. It is a lot of work, but so is debugging
> Apart from that, i'm sure that Rugby works well for simple requests
(passing a message from
> a port to another, giving date & time, even performing a small request on
> provided that the average time between 2 requests is at least the same
that a request
> processing average time...else watch out for the lag ! :)
NO! again. I use it at work over 10 machines doing database queries,
crypto'ing stuff etc. Works very fast. Remote encrypting strings (opening a
port, en / de crypting , closing ) goes easily to 100-200 /sec for most
strings of 128 bytes on a fast or giga ethernet. Encrypting takes all of
your CPU and takes much longer than the requests. But i agree that careful
programming is required, as in multithreading.
> > Another example to prove my point: Ruby, a Japanese OO-like language
> > own light-weight threading system, even on DOS! You could write a
> > light-weight threading system if you'd really wanted too in Rebol as
> Same answer as above. About Ruby, i assume that's a soft-threading model
> at the C level.
The point is that it can be done. Native threading is another process with
shared memory. And on one processor you are just switching back and
> > Now as for Rugby: you can call functions in other REBOL processes in
> > using the /deferred or /http-deferred refinements. They return
> > with a ticket number for your request. You can use this number to check
> > regularly if the result is there, and if so fetch it.
> Sure ! Multi-processing is way better that single-processing for this kind
of server !
> But multi-threading is even better :
> - Shared memory (Multitasking heaven, but notoriously difficult to deal
with!), so that
> a thread could access words from others threads and this way exchange data
> and easier than using tcp/ip connections (especially if you have a lot of
> Memory management is also more efficient. (for example: data caching)
> - Lightweight context-switching : better performance than with
I agree. But not that it is better. Shared memory almost always gives race
conditions you cannot predict. IMHO a nono.
> We need multithread to make really serious apps with Rebol, especially for
> apps ! IIRC, /Serve use multithreading internally.
Async I/O I thought ;-) Jeff, Holger?
> > t: echo/deferred "Who needs threading"
> Me and other Rebol developpers who try to find workarounds for their
projects and who could
> finally choose drastic solutions like jumping to another langague, in a
not-so-distant future. ;-)
As I try to prove, that is not necessary, though you may feel uncomfortable
with my proposed solutions of find them distasteful. Actually, I was just
trying to help in showing " that there is more than one way to do it"
> > So instead of worrying about the features not there you should look to
> > *is* there and how you can cleverly use it to solve your problems. The
> > that one paradigma is missing doesn't mean that you can't solve it
> > way. In the end it all runs on the same computer.....
> Yep, both Win3.1 and BeOS 5 run on my computer, and guess which is running
better/faster/cleaner ? ;-)
Don't mix up threading schedulers and schemes here ;-)