[REBOL] Re: Google + SOAP
From: petr:krenzelok:trz:cz at: 30-Apr-2002 19:25
Christian Langreiter wrote:
>>No, it isn't Rugby's fault, sorry :-) Your scenario is of course
>>correct, but replace Rugby and Rebol by Java, etc. - it's just the same.
>>If some func takes 10 sec, then it takes 10 sec. Maybe using Java, it
>>will be faster, but still blocking.
>>
>>
>
>Petr! NO!!! That's the point! As Java has some wondrous feature set
>collectively named "multithreading", you can write non-blocking
>servers quite easily ...
>
so you say - you "can write" ... and I mean ... you can spawn tasks
using Rebol .... in another reply someone argued that starting new task
is much more expensive. But - e.g. Apache itself uses tasks - not
threads, at least Apache 1.x family. I also heard that under Unix,
starting new task is not as much expensive as it is under Windows. I
know that stuff you are asking for does not exist, but you "can write"
it in Rebol too ... see below ...
>>1) I know where you are trying to point maybe - is that threading? Well,
>>you don't need threading to help solve it - you can launch separate task.
>>
>>
>
>Yes, you could write a "broker" which does nothing but shuffle data
>from and to "worker" processes, but that won't help you much when the
>data transfer process itself is blocking (i.e. when receiving a 10MB
>file from a client).
>
Well, then your demands are really high ...
>>5) Rugy is blocking while writing to the port, but even this can be
>>solved ...
>>
>>
>
>How so?
>
I think that Maarten has showed some example? I don't remember correctly
though. Of course streamed read/write would be cool, but we don't have
it yet. But imagine higher level function, e.g. accept-file, and client
side one - send-file. You can can just create it in higher level. Client
can set-up deferred connection, first announce server the size of file
being transferred, and you can even set-up custom protocol, e.g. first
byte having some meaning - e.g. discard transfer, etc. You can open port
to file on the client side, and open port to file on the server part, so
it will be even memory savy. I don't know how difficutl it would be, but
both sides could instlall green threads, to process transfer in the
background ...
>>6) Ppl should calm down sometimes :-) Do you want to run server being
>>accessed by 10 ppl a sec, so generating 600 request per minute?
>>
>>
>
>There are lots of scenarios where I'd like to use REBOL as an
>in-memory data engine and where one web request (e.g.) could easily
>result in about 50 queries to that data "server", some of which might
>well take some time to complete. So it's absolutely realistic and
>there's nothing to "calm down".
>
I really mean it :-) Just replace REBOL above with the word Apache. It
listens on 80 port and serves many clients, not using threading, but
tasks, which can be pre-started. You could also program some basic
load-balancing for Rugby ...
Of course I would be glad too, if we had fully async stuff already, and
some kind of similar framework would exist .... But I think that
community even haven't pushed Rugby to its limits ... But I am
occassional Rugby tester - it would be maybe good to let's Maarten to
comment ... :-)
>>7) Have you ever tried Rugby? :-)
>>
>>
>
>Yes. Indeed I have written a simple file-sync utility with Rugby (not
>unlike Novell's iFolder, but without all the features ;-). It started
>to eat up memory after awhile and I never came around to really debug
>it ...
>
... yes, it was happening to me too, at least with some earlier
versions. My Apache fast-cgi process went to some 80% usage and was
eating resources up. Maybe it was not Rebol/Rugby's fault ... who knows ...
Cheers,
-pekr-
