Ideas to simulate a multithreaded sockets server

Bernard Devlin bdrunrev at
Sat Feb 27 04:43:17 EST 2010

On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni
<marcio at> 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: .
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 (



More information about the Use-livecode mailing list