This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


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

Re: vfscanf in newlib


----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-developers-digest-help@cygwin.com>;
<cygwin-developers@cygwin.com>; <newlib@sources.redhat.com>
Sent: Sunday, April 22, 2001 9:25 AM
Subject: Re: vfscanf in newlib


> On Sat, Apr 21, 2001 at 01:38:58PM -0400, Charles S. Wilson wrote:
> >Didn't somebody already do a threadsafeness audit of newlib?  If so,
> >then we don't want to break threadsafeness with these changes.  I'm
not
> >familiar with threaded code in C; what is neccessary to insure that a
> >given function is both reentrant and threadsafe (if a block of code
is
> >threadsafe it is automatically reentrant, but a reentrant block is
not
> >necessarily threadsafe, right?)

Correct. re-entrant code does not uses passed parameters, read-only data
and local-nonstatic variables only. Any exceptions to that list are
protected by mutex's/critical sections and the like. Essentially calling
the same function while another process or thread is paused within it
won't cause problems. Threadsafe adds the requirement that concurrent
processing of the code (say on two threads executing on two processors)
will not cause problems. This generally involves syncronising all access
to non-local variables (in addition to the reentrant requirements).
(Syncronisation can be as simple as using InterLockedExchange when
adding to a list, or as complex as mutex and condition vars with
trylock()s and more.)

> That's right.
>
> AFAIK, newlib is not guaranteed to be thread safe.
>
> So, I guess that Cygwin is, by extension, not really thread safe
either.
>
> I can think of a few functions in cygwin that are not thread safe, in
> fact.  The enviroment manipulation is not thread-safe.  I don't
believe
> that vfork is thread safe.  I'm sure that there are many others.

Well the SUS doesn't require libc to be thread-safe. It only requires
the thread-safe functions (not all of which are named _r) to be
threadsafe. IMO we should only introduce _r versions of functions when t
hey are thread-safe.

Rob

>
> cgf
>


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