Ideas to simulate a multithreaded sockets server

Marcio Alexandroni marcio at cialogica.com.br
Sat Feb 27 06:31:38 EST 2010


Hi Bernard,

I visited the page about the mechanism you pointed, but in that case it has
an Apache/PHP server that handles multiple concurrent connections but it
ends up passing the request to a Rev application using Sockets that will
cause the same queuing on message processing. In fact, the requests to the
server are multithreaded but the processing is not, as I could understand.
Did I understand it right?

Regards,

Marcio Alexandroni
www.cialogica.com.br
 ( (11) 9989-8316
  marcioalexandroni
-- 



> 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
> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution





More information about the use-livecode mailing list