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

[REBOL] Re: why Rugby uses async I/O

From: holger:rebol at: 23-May-2001 11:13

On Wed, May 23, 2001 at 07:05:25PM +0200, Maarten Koopmans wrote:
> Second, Rebol is its own reflexive metalanguage. So once a thing like async > I/O is there, the rest is syntactic sugar. Why change the API? Why not > built on top? I know, this is the discussion you don't want (Holger), but I > can always ask ;)
The async-modes stuff was not "designed" the way we usually do. It was a quick hack which bypasses most of the port API so the lower layers do not block any more than they have to. We needed this for RMP (our encryption, session, messaging, transport and tunnelling layer for /Express). It was never intended to become part of any official API. The result is rather messy. It requires polling from the main code, catching errors etc., but it works and required few changes to the existing port code, which was good enough to get /Express released. It is too different from the way we would like async ports to work though, for it to be useful as a foundation for a new API. The "real" async port API will be handler-based and much nicer to work with, closer to the way View event ports work. Among other things it lets you deal with proxy servers transparently, and all port actions are handled in the background. You could, e.g., download several files by HTTP in parallel, streamed to local files, at the same time that you are typing REBOL commands at the console prompt.
> One more thing: copy/part on an async port seems to eat up memory (hence I > use read-io), bug?
That may very well be. Setting async-modes disables large portions of the port code, and the result may very well be inconsistent. One reason why this should not be used in any other way than within our RMP engine :-). -- Holger Kruse [holger--rebol--com]