radiusclient thread-safety

[Alex Massover]

Hi,

Here's a small non-reentrant clean-up patch:
a) localtime(), gmtime(), getserbyname(), rand() switch to _r interfaces
b) inet_ntoa -> inet_ntop
c) poll() expect timeout in milliseconds, not in microseconds
d) request id is now just pre-increment - faster and simplier than random

> -----Original Message-----
> From: freeradius-devel-bounces+alex=jajah.com at lists.freeradius.org
> [mailto:freeradius-devel-bounces+alex=jajah.com at lists.freeradius.org]
> On Behalf Of Alan DeKok
> Sent: יום ג 02 מרץ 2010 10:23
> To: FreeRadius developers mailing list
> Subject: Re: radiusclient thread-safety
> 
> Alex Massover wrote:
> > Also regardless of rc_handle the lib has a lot of non-reentrant
> > functions (inet_ntoa, localtime, gmtime, random, rand...).
> > Does it supposed to be thread-safe even if there's no logical
> > issue with rc_handle?
> 
>   Probably not.
> 
>   For a thread-safe RADIUS client library (LGPL), see freeradius-
> server,
> src/lib.  See src/main/radclient.c for an example client.
> 
>   The client doesn't use threads.  But the functions in src/lib are
> thread-safe if they're protected by a mutex lock.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
> 
> This mail was received via Mail-SeCure System.
> 


This mail was sent via Mail-SeCure System.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: reentrant.patch
Type: application/octet-stream
Size: 5346 bytes
Desc: reentrant.patch
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20100302/82bc00ec/attachment.obj>