(RADIATOR) threading

[Guðbjörn S. Hreinsson]

> PS: I don't agree in the fact that you say that threading won't
> necessarily improve anything. Threads tend to be much faster to create,
> and use less memory than forked processes. I agree, perl doesn't fully
> take advantage of this yet, but they will once - and we should better be
> ready for it. ;)

I would have to agree with this, but not only from performance perspective. 
radiator today is a single pipeline with multiple stopovers (depending 
on config), all incoming packets have to wait for the processing of the 
preceding packet. If a single packet gets processed slowly for some reason 
all packets have to wait. You can build multiple instances (poor man's 
threading?) per accounting and authentication/authorization and multiple 
instances per NASes and/or NAS groups but this tends to complicate things 
and make management more difficult. Of course you need to maintain the 
performance level of all backends but perusing thread models can only 
give a more reliable, higher performing and better resource performance 
than a single process model. 

Just my ISK 0.2
-GSH


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.