This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libm reentrancy


Oh yeah, forgot about errno. I guess the best way to avoid that is to make sure the number you are taking the square root of isn't negative. -- Gregory

On 1/9/2013 4:37 AM, Marcus Hult wrote:
Hello,

Thanks for your reply Gregory.

The sqrt function for instance, may set the errno variable according
to the manual. Shouldn’t this function then have a reentrant version?
Or do I always need to use the _impure_ptr when using libm, to be thread safe?

/Marcus

On Tue, Jan 8, 2013 at 2:45 PM, Gregory Pietsch <gpietsch@comcast.net> wrote:
On 1/8/2013 6:36 AM, Marcus Hult wrote:
Hello,

I am a bit confused about reentrancy in the newlib libm. I have read
the explanation about the _REENT_ONLY flag here:
http://www.sourceware.org/ml/newlib/2003/msg00697.html.

Most functions in libm does not have an _r version, but when defining
the symbol _REENT_ONLY, a lot of those functions are ifndef'ed out.
Why are there no reentrant versions of these functions? And how is the
_REENT_ONLY flag supposed to be used with libm?

To make these functions in libm thread safe, i guess i need a _reent
struct in each thread and set the _impure_ptr to this when switching
tasks? Or how can i assure the libm function calls are thread safe?

Thanks in advance

Most of the libm functions do not need to change any external state, so they
should be thread-safe. The only ones I can think of that would be affected
would be the functions in fenv.h because they rely on two external states.
Any other comments?

Gregory


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]