Mail Archives: cygwin-developers/2001/04/21/13:44:10
> Subject: Re: vfscanf in newlib
> Date: Sat, 21 Apr 2001 11:05:08 +0200
> From: Corinna Vinschen <vinschen AT redhat DOT com>
> Reply-To: Corinna Vinschen <cygwin-developers AT cygwin DOT com>
> To: cygwin-developers AT cygwin DOT com
>
> On Sat, Apr 21, 2001 at 01:21:30AM -0400, Charles Wilson wrote:
> > I've just discovered that I get a coredump with all three when I try to
> > run ssh. #$!@&$
>
> I just build the latest from CVS and it's running fine, even ssh and
> sshd.
>
> Corinna
Thank you. I guess that means the answer from my email is #3: I've
somehow lost the ability to build a working cygwin snapshot from a
perfectly good codebase. Funny, I don't remember the surgeon saying
"Ooops" during my recent brain surgery.... :-)
--Chuck
> Subject: Re: vfscanf in newlib
> Date: Sun, 22 Apr 2001 00:05:36 +1000
> From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> CC: <cygwin-developers AT cygwin DOT com>,
> <jjohnstn AT cygnus DOT com>
>
> ----- Original Message -----
> From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> Cc: <cygwin-developers AT cygwin DOT com>; <jjohnstn AT cygnus DOT com>
> Sent: Saturday, April 21, 2001 3:21 PM
> Subject: Re: vfscanf in newlib
>
> > Robert Collins wrote:
> > >
> > > A __cursory__ conde read through gives me the impression that
> > > simultaneous calls with the same file may result in undefined results.
> > >
> > > buffer wise it should be ok, but don't use the same handle twice. I
> > > don't know that the SUS has to say about the _r function w.r.t. the file
> > > in use, but I would expect that two calls from two threads to one of the
> > > _r functions should result in one blocking until the other finishes
> > > scnaning, not them interleaving fread calls.
> > >
> > > I may be completely off-base here though.
> >
> > Maybe. I just discovered something -- which *MAY* be related to my
> > changes, or *MAY& be related to other changes. I've built three
> > cygwin1.dll's in the last two days.
>
> I'm looking at the original function that you are wrapping: I don't
> think your changes will make it worse, just that the _r functions may be
> reentrant, but not threadsafe. That may be an issue with increasing
> threaded applications on cygwin...
>
> I don't think this should stop the code going in, just that someone
> should go through that code carefully.
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?)
--Cbuck
- Raw text -