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]