No subject

it appears to behave radically different on different OSes, presumably
because every OS treats threading differently.

This may be the reason for the non-production-quality aspect.

Chris

> From: Hugh Irvine <hugh at open.com.au>
> Organization: Open System Consultants
> Reply-To: hugh at open.com.au
> Date: Thu, 28 Feb 2002 11:17:15 +1100
> To: Damir Dzeko <damir.dzeko at iskon.hr>
> Cc: radiator at open.com.au, mikem at open.com.au
> Subject: Re: (RADIATOR) AuthRADIUS (non)forking problem
> 
> 
> Hello Damir -
> 
> Mike and I have discussed this issue at length over a long period of time,
> and indeed the topic has also been discussed on the mailing list several
> times as well.
> 
> Basically, it is our intention to extend Radiator to use multi-threading so
> that each request runs in a separate thread, which we feel is the best
> approach for dealing with all these sorts of problems (not just with AuthBy
> RADIUS clauses).
> 
> The only reason that this has not been done yet is due to the fact that
> although there is experimental support for multi-threading in Perl now, it is
> specifically stated that it is not to be considered "production-quality" code.
> 
> This being the case, we have opted to wait until there is a solid
> multi-threading release of Perl first before spending more time on it.
> 
> regards
> 
> Hugh
> 
> 
> On Wed, 27 Feb 2002 19:55, Damir Dzeko wrote:
>> Hugh Irvine <hugh at open.com.au> writes:
>>> Hello Damir -
>>> 
>>> As always, many thanks for your very valuable contributions.
>>> 
>>> Mike will apply the fixes for the next release.
>> 
>> My coleagues & I are discussing an interesting idea. Would it
>> be possible to handle slow AuthRADIUS proxy requests in a single
>> process (forked out of main radiusd)?
>> 
>> That process would have a communication line with main radius
>> daemon through some socket (or whatever) and handle all slow
>> requests in one big select loop (instead of forking an extra
>> process to do the job for less then a few packets). That would
>> make more efficient use of system resources.
>> 
>> -d
> 
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> ===
> 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.

===
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.