Date: Sun, 9 Feb 2003 21:30:50 -0600 From: David Leimbach <leimy2k@mac.com> To: Juli Mallett <jmallett@FreeBSD.ORG> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: thread safety Message-ID: <0D6B31A1-3CA8-11D7-8E7D-0003937E39E0@mac.com> In-Reply-To: <20030209212033.A23910@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, February 9, 2003, at 09:20 PM, Juli Mallett wrote:
> * De: David Leimbach <leimy2k@mac.com> [ Data: 2003-02-09 ]
> [ Subjecte: thread safety ]
>> This function has a time_t value which is static. I don't think this
>> function, the
>> way it appears to be designed, can easily be made thread safe as a
>> result.
>
> Passing in pointers to storage that used to be static (and then making
> the original a wrapper that passes in the static storage) is OK?
Hey Juli! :)
That would work... In fact in Darwin they take the extra user
parameters from
getpwnam_r for the user pointer and pass it all the way down to the
actual
db lookup functions.
Unfortunately there is global data in the nsdispatch.c file as well
that is
used to show state of the various functions contained in that file...
Luckily this data is static and not exposed to other CUs.
I was just thinking... if we rewrote all of libc to be re-entrant and
thread safe
the thread unsafe versions can easily be wrappers around the thread
safe ones.
void foo_r (char * data)
{
//do something and put it in data
}
void foo ()
{
static char byte_array[BIGSIZE];
foo_r(byte_array);
...
}
Etc.
That would make the performance of the unsafe functions suck potentially
but its easier to go back and re-write those IMO than to develop an
execution
path that is fully thread safe as an afterthought.
*sigh* :)
Its a good challenge anyway.
All thread safe functions should be in libc_r? I don't see too much in
there is
why I ask.
Dave
> --
> Juli Mallett <jmallett@FreeBSD.org>
> AIM: BSDFlata -- IRC: juli on EFnet
> OpenDarwin, Mono, FreeBSD Developer
> ircd-hybrid Developer, EFnet addict
> FreeBSD on MIPS-Anything on FreeBSD
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-standards" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D6B31A1-3CA8-11D7-8E7D-0003937E39E0>