Mail Archives: cygwin/2001/07/21/20:17:00
----- 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/
- Raw text -