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,
P.
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
www.cialogica.com.br
( (11) 9989-8316
marcioalexandroni
--
From: Bernard Devlin <[email protected]>
Reply-To: How to use Revolution <[email protected]>
Date: Sat, 27 Feb 2010 09:43:17 +0000
To: How to use Revolution <[email protected]>
Subject: Re: Ideas to simulate a multithreaded sockets server
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
_______________________________________________
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
--
Pierre Sahores
mobile : (33) 6 03 95 77 70
www.woooooooords.com
www.sahores-conseil.com
_______________________________________________
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
