[REBOL] Re: P2P Q&A
From: koopmans:itr:ing:nl at: 2-Oct-2001 16:04
Ok, this one is gonna be lengthy....
Pekr, the discussion I had with Holger was about how to implement async I/O.
Hence your confusion.
Now for multithreading / async I/O:
The first thing to realize is that threads are really processes with shared
memory. (And shared memory is the root of all evil.....) This also implies
that mutli-threading for performance is only really working on multiple
processor systems. Most systems converge to one processor because of price,
especially for end-users.
Async I/O will be very nice, but what's really sufficient for most people is
a feature Rebol already has: non-blocking I/O This means that you can open a
tcp connection (for example) and check every now and then if there is data,
copy it, do something else etc.
Concurrent behaviour can be achieved by cleverly combining non-blocking I/O
with system/ports/wait-list and the view event system, especially if you have
your own event loop written. A good point to remember here is that in the end
your O/S (at least formost of us) also runs one processor. Now I am not
saying that you should write your own OS, it's merely a blunt reminder that
most things can be done in most environments if you really want to (threading
at the interpreter level, implemented in REBOL for example).
Take a look at the rugby console (rugby-console.r) on the REB, for example.
It runs a server while you can type on the console in Core 2.5
Another example to prove my point: Ruby, a Japanese OO-like language with its
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 well.
Now as for Rugby: you can call functions in other REBOL processes in Rugby
using the /deferred or /http-deferred refinements. They return immediately
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.
This is done by using a client-side non-blocking TCP port. Every time you
call result-available? <ticket> it just copies whatever it can from the TCP
port and checks to see if the result is completely there. If so it returns
true, otherwise false. If you get true, you simply call get-result <ticket>
and the result is there.
NOTE: it looks like this is not working on NT 4.0 sp3. All other platforms
are OK.
A sample, presuming the sample echo server is running:
;load rugby
do %rugby.r
;This loads the rugby sample echo function on the client
do get-rugby-service/http http://localhost:8002
t: echo/deferred "Who needs threading"
while [ not result-available? t ]
[
print "Doing nothing useful"
print "But something different than fetching the echo"
]
;Now the result is there
print get-result t
So instead of worrying about the features not there you should look to what
*is* there and how you can cleverly use it to solve your problems. The fact
that one paradigma is missing doesn't mean that you can't solve it another
way. In the end it all runs on the same computer.....
--Maarten
