Mail Archives: cygwin-developers/2001/04/21/20:15:07
----- Original Message -----
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>; <newlib AT sources DOT redhat DOT com>
Sent: Sunday, April 22, 2001 10:12 AM
Subject: Re: vfscanf in newlib
> ----- Original Message -----
> From: "Christopher Faylor" <cgf AT redhat DOT com>
> To: <cygwin-developers-digest-help AT cygwin DOT com>;
> <cygwin-developers AT cygwin DOT com>; <newlib AT sources DOT redhat DOT 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
Typo! "only uses"
> 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
> >
>
>
- Raw text -