why Rugby uses async I/O
[1/5] from: m::koopmans2::chello::nl at: 23-May-2001 19:05
First of all, it's there and it's the best solution for what Rugby needs to do, IMHO. If it breaks with 3.0, too bad. It took me a day to write it, and if 3.0 improves the API it will take less than a day to change it. But 3.0 goes into the category "more than 6 months away", so I'll live on the edge for now. 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 ;) I don't like the "don't use" mantra. If it's there you may use it at your own risk, once you know the risks. An API change is the least problem in a productive thing like REBOL. Lack of features is much more serious. So why should yourself in the foot (RT)? One more thing: copy/part on an async port seems to eat up memory (hence I use read-io), bug? Finally, I'll update Rugby to the 3.0 APIs once it gets here. Right now I am adding security for the Pro users, top-level mezzanines, and deferred client calls (non-blocking). Coming soon to a computer near you... I am looking into SOAP support. Any help there is appreciated! I am thinking of a CGI front-end that utilizes Rugby and provides SOAP marshaling. Once I have that we are ready to blow away .Not Speaking of publicity then :) --Maarten
[2/5] 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]
[3/5] from: sanghabum:aol at: 23-May-2001 14:21
> [m--koopmans2--chello--nl] writes: > So why > should yourself in the foot (RT)?
Has anyone as yet contributed a "How to shoot yourself in the foot" function with Rebol? If not, it must be the only programming language without such an example. <g> Colin.
[4/5] from: m:koopmans2:chello:nl at: 23-May-2001 20:50
Points taken and understood. I'll just update Rugby to Core 3.0 once you enter the beta cycle, that way nobody gets hurt. I only released Rugby because it turned to be better than I expected. I am pleasantly surprised that I'm not the only one there. In essence we both do the same: using async for a protocol on top of TCP. Be careful with that copy/part though. Doing things in the background suggests that you switch to a multithreaded stack-based machine?
[5/5] from: holger:rebol at: 23-May-2001 13:54
On Wed, May 23, 2001 at 08:50:42PM +0200, Maarten Koopmans wrote:
> Doing things in the background suggests that you switch to a multithreaded > stack-based machine?
No, still single-threaded, but switching to a state machine-driven protocol engine, triggered from within 'wait and some other natives. -- Holger Kruse [holger--rebol--com]