Ideas to simulate a multithreaded sockets server
bdrunrev at gmail.com
Sat Feb 27 04:43:17 EST 2010
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)
More information about the Use-livecode