Hi Bernard, Thanks very much for your suggestions.
I've been reading about Rev and CGI, but I read on rev Forums that the necessary standalone engine necessary for the cgi-bin support is available only on Rev <= 3.5, the new versions do not have the standalone engine anymore. Do you know if it's true? On the other side, I'll test your suggestion on waiting with messages where it could take longer to answer, I'll do it right now. Regards, Marcio Alexandroni ( (+55 11) 9989-8316 Skype: marcioalexandroni Brazil -- > From: Bernard Devlin <[email protected]> > Reply-To: How to use Revolution <[email protected]> > Date: Sat, 27 Feb 2010 09:43:17 +0000 > To: How to use Revolution <[email protected]> > Subject: Re: Ideas to simulate a multithreaded sockets server > > On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni > <[email protected]> wrote: >> The applications runs pure TCP/IP with a custom protocol to exchange data >> and it handles dozens of simultaneous calls at the same time, this is why it >> must be multithreaded, the queuing will not work in this case because of the >> time it would need to respond to the last caller. > > Hello Marcio, your fellow Brazilian is one of the experts on rev-built > http servers, so I'm sure he'll answer your question in detail soon. > > However, whilst he's sleeping, let me just point you to this > mechanism: http://www2.sahores-conseil.com/insead/index_en.html . > Pierre used that mechanism deployed (I believe) to the French Ministry > of Education, and it was a system used by students across France. > Since you need raw TCP/IP it doesn't sound like it will meet your > needs. > > Whilst Rev is not multi-threaded, can I just ask if you are using the > following format in your code: > > accept [datagram] connections on port number with message callbackMessage > > If so, then elsewhere in your code you may be able use the following > structure at places where you can accept potential interruptions: > > wait 10 milliseconds with messages > > When an existing connection's processing gets temporarily suspended by > the "wait", it means that a new connection can be accepted and > processing for that new connection can begin. > > These two together can provide a kind of message-passing concurrency. > For example, that is similar to the way that 'concurrent' processing > is done in Tcl (http://www.stanford.edu/~ouster/cgi-bin/papers/threads.pdf) > , > > Regards, > > Bernard > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
