On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni <[email protected]> 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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
