• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: possibly OT: threadsafe libc
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: possibly OT: threadsafe libc


  • Subject: RE: possibly OT: threadsafe libc
  • From: Philip Lukidis <email@hidden>
  • Date: Mon, 21 Nov 2005 13:14:27 -0500

Thanks for your answer, it puts my mind at ease.  It's just that in Win32
you must specify which C library you wish to use, and not all are
threadsafe.  Since I did not see an equivalent approach here, and could
not find official documentation, I had some doubt in my mind.  But now
that doubt is put to rest.

thanks,

Philip Lukidis

> -----Original Message-----
> From: Eric Albert [mailto:email@hidden]
> Sent: Monday, November 21, 2005 12:45 PM
> To: Philip Lukidis
> Cc: email@hidden
> Subject: Re: possibly OT: threadsafe libc
>
>
> On Nov 21, 2005, at 7:03 AM, Philip Lukidis wrote:
>
> > Hello.  I was wondering if there was a fully threadsafe libc
> > version which I
> > can use.  I'll be using pthreads and was hoping there would be an
> > easy way
> > to know which libraries are threadsafe or not.
> >
> > Does Apple formally specify which functions in libc are
> > threadsafe?  I have
> > heard that several libc functions have a _r version, but
> was hoping
> > that
> > there would be a fully threadsafe library which I can link
> to.  For
> > example,
> > sprintf does not have a _r version...does that mean I have to wrap
> > sprintf
> > calls with a mutex?  I would assume not, but this would be my
> > intuition
> > speaking and not a formal written declaration by Apple on which
> > libraries/calls are threadsafe.
> >
> > So, how to absolutely know if a libc call is threadsafe?
>
> It's unfortunate that we haven't yet documented the thread safety of
> Libc in the same way as, say, Sun does for its man pages.  However,
> all of Libc is threadsafe except where it's explicitly
> documented not
> to be...and I can't think of any cases in which it's documented to
> not be threadsafe.  Mac OS X uses multiple threads very extensively,
> so a threadsafe Libc is essentially required.
>
> Where _r functions are available, they're provided for compatibility
> or because some folks find the extra context argument useful, not
> because the non-_r version is not threadsafe.
>
> As for sprintf specifically, I wonder how anyone would implement a
> non-threadsafe version.  I suppose calling it with the same
> destination buffer from two threads simultaneously probably wouldn't
> work out well, but expecting that to produce useful results anywhere
> just doesn't seem like a good idea in the first place.
>
> -Eric
>
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Re: possibly OT: threadsafe libc
  • Next by Date: Re: Target setup for unit testing (using cppunit)
  • Previous by thread: Re: possibly OT: threadsafe libc
  • Next by thread: RE: possibly OT: threadsafe libc
  • Index(es):
    • Date
    • Thread