Ideas to simulate a multithreaded sockets server

Pierre Sahores psahores at
Sat Feb 27 07:06:09 EST 2010

Hi Marcio,

Did you have an eye to the on-rev / irev technology. It's definitively  
the most usable way to go, from yet. Even if CGI and PHP/Rev Stacks  
went good underground ways to use, over the 15 past yahrs, the  
revServer witch will be made public and free available in the  
forecoming months by RunRev is a very stable et fast running engine  
from yet.

About your multi-threading need, i can't help, for yet, as long as we  
can't see how the revServer is / is'nt able for yet (it could be, at  
least with a adapted xinetd config under linux - i did so for metacard/ 
suse, yahrs ago) to handle multi-thread.

Instead of devlopping your own framework first, why would you not try  
to test your project design in using the on-rev platform ? I use it  
for my own (two projects up and running, the thirst is on desk) with  
great satisfaction.

Kind regards,


Le 27 févr. 10 à 12:31, Marcio Alexandroni a écrit :

> 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
> ( (11) 9989-8316
>  marcioalexandroni
> -- 
>> From: Bernard Devlin <bdrunrev at>
>> Reply-To: How to use Revolution <use-revolution at>
>> Date: Sat, 27 Feb 2010 09:43:17 +0000
>> To: How to use Revolution <use-revolution at>
>> Subject: Re: Ideas to simulate a multithreaded sockets server
>> 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
>> 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 ( 
>> )
>> ,
>> Regards,
>> Bernard
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription
>> preferences:
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:

Pierre Sahores
mobile : (33) 6 03 95 77 70

More information about the Use-livecode mailing list