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


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