Success with pthreads-win32 + gcc/mingw

Success with pthreads-win32 + gcc/mingw

[Mumit Khan]

I finally had the time to write a first-cut win32 thread support for gcc 
runtime, and now all the tests pass when I build with mingw/msvcrt port
of gcc-2.95.

However, I believe that most of the tests were failing earlier due to 
configuration bugs:

  - DllMain@12 is not an entry point as done in the Makefile. That should
    be removed. The entry point is _DllMainCRTStartup, which is taken
    care of automatically. The defaults will work just as well.
  - there are some issues with the thread startup routine passed to
    _beginthreadex. It *has* to be defined __stdcall as well.
  - few nits here and there.

I'll send my changes along after I do a few more tests, and integrate my
changes into an updated CVS tree. 

I'd also like to add support for CRTDLL, but I need to take a look at how
the extra parameters to _beginthreadex that is not in _beginthread is 
being used. beginthread will always start the thread running, and also
doesn't return the thread id (which you can get in other ways of course).

Others will not be able to build it with gcc-2.95 release unfortunately; If
things go well, I'll put together a thread-safe runtime package as an add
on (just libgcc.a if I remember correctly).

Regards,
Mumit

Re: Success with pthreads-win32 + gcc/mingw

[Mumit Khan]

On Tue, 17 Aug 1999, Bossom, John wrote:

> Yikes! DllMainCRTStartup is not the same as DllMain.
> Are you replacing DllMainCRTStartup with the DllMain provided by
> pthreads-win32?

I should've pointed out that I *am* using DllMain provided by pthreads,
and not replacing it in any way. In fact, my changes to pthreads are just 
a few lines.

What I'm pointing out is that DllMain is *not* the entry point. This is 
a common misconception that DllMain is somehow the entry point; in fact, 
DllMain is just something called by the entry point (just like main or
WinMain@16 is called by the entry point), which needs to do some magic 
beforehand. The Mingw runtime provides DllMainCRTStarutp, the entry point, 
and very rarely do you need to change. 

Essentially all that needs to be done is to remove the -e DllMain@12
argument, and then the startup calls DllMain@12 correctly and everything
works. 

If you provide a DllMain, startup calls that (as is the case here); if you
don't, the library provides a default stub.

> Without the DllMain, thread cleanup and tsd destructors will not happen.

Yes, I know.

> _beginthreadex is responsible for ensuring that the CRT is initialized for
> the
> thread.

I know. CRTDLL uses beginthread and MSVCRT _beginthreadex, and there are
small, but very important, differences. 

Regards,
Mumit

RE: Success with pthreads-win32 + gcc/mingw

[Bossom, John]

Yikes! DllMainCRTStartup is not the same as DllMain.
Are you replacing DllMainCRTStartup with the DllMain provided by
pthreads-win32?

Without the DllMain, thread cleanup and tsd destructors will not happen.

_beginthreadex is responsible for ensuring that the CRT is initialized for
the
thread.

-----Original Message-----
From: Mumit Khan [ mailto:khan@xraylith.wisc.EDU ]
Sent: Tuesday, August 17, 1999 3:48 PM
To: pthreads-win32@sourceware.cygnus.com
Subject: Success with pthreads-win32 + gcc/mingw 


I finally had the time to write a first-cut win32 thread support for gcc 
runtime, and now all the tests pass when I build with mingw/msvcrt port
of gcc-2.95.

However, I believe that most of the tests were failing earlier due to 
configuration bugs:

  - DllMain@12 is not an entry point as done in the Makefile. That should
    be removed. The entry point is _DllMainCRTStartup, which is taken
    care of automatically. The defaults will work just as well.
  - there are some issues with the thread startup routine passed to
    _beginthreadex. It *has* to be defined __stdcall as well.
  - few nits here and there.

I'll send my changes along after I do a few more tests, and integrate my
changes into an updated CVS tree. 

I'd also like to add support for CRTDLL, but I need to take a look at how
the extra parameters to _beginthreadex that is not in _beginthread is 
being used. beginthread will always start the thread running, and also
doesn't return the thread id (which you can get in other ways of course).

Others will not be able to build it with gcc-2.95 release unfortunately; If
things go well, I'll put together a thread-safe runtime package as an add
on (just libgcc.a if I remember correctly).

Regards,
Mumit