Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <3AE1C5B2.B63F2B54@ece.gatech.edu> Date: Sat, 21 Apr 2001 13:38:58 -0400 From: "Charles S. Wilson" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin-developers-digest-help AT sources DOT redhat DOT com CC: cygwin-developers AT sources DOT redhat DOT com, newlib AT sources DOT redhat DOT com, jjohnstn AT cygnus DOT com Subject: Re: vfscanf in newlib References: <987861904 DOT 20126 DOT ezmlm AT sources DOT redhat DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Subject: Re: vfscanf in newlib > Date: Sat, 21 Apr 2001 11:05:08 +0200 > From: Corinna Vinschen > Reply-To: Corinna Vinschen > 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" > To: "Charles Wilson" > CC: , > > > ----- Original Message ----- > From: "Charles Wilson" > To: "Robert Collins" > Cc: ; > 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