[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]
