Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <053201c11242$c07ddca0$806410ac@local>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Mo DeJong" <mdejong AT cygnus DOT com>, <cygwin AT cygwin DOT com>
References: <Pine DOT SOL DOT 3 DOT 91 DOT 1010721141254 DOT 14945C-100000 AT cse DOT cygnus DOT com>
Subject: Re: Linking to cygwin1.dll and msvcrt.dll ?
Date: Sun, 22 Jul 2001 10:10:43 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 21 Jul 2001 23:57:13.0385 (UTC) FILETIME=[DCBFD190:01C11240]


----- Original Message -----
From: "Mo DeJong" <mdejong AT cygnus DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Sunday, July 22, 2001 7:26 AM
Subject: Re: Linking to cygwin1.dll and msvcrt.dll ?


> On Fri, 20 Jul 2001, Mumit Khan wrote:
>
> ...
>
> > > My question is, is this same memory leak problem going
> > > to show up when using Cygwin's CreateThread() and
> > > C library APIs?
> >
> > I believe the memory leak is only applicable if you're using MSVCRT
> > runtime, but that's not the case with Cygwin. The *ex functions close
> > the various handles and TLS' that are created per thread if I remember
> > correctly.
>
> The way I understood it, calling CreateThread() would not create the
> TLS block and a later call to a C api function might allocate
> the TLS block for you. Later on, you would call ExitThread() the
> the TLS block that was allocated would not be deallocated and
> the memory would leak.

I'm not sure that the emory leak referenced was the TLS area. TLS on pre
win2k had only 64 entries, which implied a static block as part of the
thread information . On 2k the TLS memory area may be reserved dynamically,
but recall that the same amount of storage is needed in all threads of the
sae process (ie if you have 3 TLS keys, storage for 3 LPTR's are neeed _per
thread_.

The way I read the MS advisory was that there C library was not native-win32
thread-safe/aware unless those acros were used.

> > It's tempting, but IMO Cygwin should stay away from creeping feature'ism
> > such as this. Most of the threaded applications I see tend to use Win32
> > API directly, and Cygwin of course supports that just fine. Of course,
we
> > can always have msvcrt helper/port library that can facilitate ports.

I like this idea - if those macro calls are needed by programs.

> If the app uses only the Win32 API then I don't think this problem
> shows up. It only applies when a thread created with CreateThread()
> calls C APIs. I don't even know if this is a problem in Cygwin
> since as far as I know Cygwin does not implement C function is
> the same way as msvcrt.dll.

Correct. We don't use the MS C library. We don't have that problem. However
the request for these calls was made on the basis that someone's program
ported to MSVC needed them if built under cygwin - which is false - they're
not needed under cygwin :].

> I am not in a position to judge "creeping feature'ism". It is
> just that these 4 *ex methods are documented and are even
> suggested in the Microsoft documentation. If this memory
> leak is not a problem in Cygwin, then these functions
> should be really easy to implement since they would just
> call the Win32 APIs.

They are suggested to work around MS's inability to write high-quality code.
The calls would be easy to implement yes, but there is no point in putting
them in *cygwin*.

Rob

> cheers
> Mo
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/