(RADIATOR) threading

[Andy De Petter]

Tariq Rashid wrote:

> disagree - the granularity of perl/python languages is not as fine as to
> allow much benefit. this is acknowledged by the perl and python developers.
> the locks are too big!
> 
> for serious "concurrent" work using these languages, you are better of using
> state-tables and event-driven asynchronous handling. 
> 
> so for perl/python your best bet is to use a proxy whoch forwards to
> multiple radiator instances (prefereable on different machines). and in this
> case i recommend using a C-based proxy as my own experiments have found that
> the perl one at radiatr version 3.8 wasn't that great with latency.
> 

You would still be stuck with maximum 1 request being handled, per 
different instance you're running - which is unacceptable from large ISP 
point of view.

Either way, if open consultants would be supporting the multi-threading 
(even in pre-alpha state, or whatever), people would at least have the 
choice of using it - and everyone using radiator, would be able to share 
experiences, of whether it's more or less performant, and come to 
conclusions afterwards ..

Keep adding those 2 cents, and we'll get rich eventually.. >8)

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3322 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.open.com.au/pipermail/radiator/attachments/20041026/3dd75715/attachment.bin>