This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linking to cygwin1.dll and msvcrt.dll ?



----- Original Message -----
From: "Mo DeJong" <mdejong@cygnus.com>
To: <cygwin@cygwin.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]