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- >Bye, >-- Chris > > > > > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
