Ideas to simulate a multithreaded sockets server
marcio at cialogica.com.br
Sat Feb 27 05:17:05 CST 2010
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.
( (+55 11) 9989-8316
> From: Bernard Devlin <bdrunrev at gmail.com>
> Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
> Date: Sat, 27 Feb 2010 09:43:17 +0000
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Subject: Re: Ideas to simulate a multithreaded sockets server
> On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni
> <marcio at cialogica.com.br> 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
> 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)
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the use-livecode