RE: gcc mingw/crtdll patch

RE: gcc mingw/crtdll patch

[Bossom, John]

With regards to the return code not working...
In my original contributed work, the pthread_t structure contained
an unused attribute, "exitStatus" that can be used precisely for
the purpose of implementing the return code.

I didn't bother to use it since _endthreadex and GetExitCodeThread
did the trick just fine for WIN32.

However, if you need to use an alternative method, you simply can
do the following:

1) pthread_exit - stuff the result in t->exitStatus.
2) In _pthread_threadStart (?) if the user's thread routine actually
   returned, then stuff the return value in t->exitStatus.
3) In pthread_join, if the thread had terminated, simply extract
   the exit status from the instance of the thread structure.

If, however, you cannot use _endthreadex, the way to implement pthread_exit
is to throw the result as an exception back to an exception handler
in _pthread_threadStart and then stuff the result into the pthread_t there.
The trick, however, is trying to satisfy both C and C++ for throwing the
exception.
All the documentation I have read on C++ and pthreads is to never call
pthread_exit
from anywhere else but your thread main-line so that you do not circumvent
stack unwinding.

Just my 2 cents...

Sorry if I seem ignorant to what you are trying to do...

John.

-----Original Message-----
From: Mumit Khan [ mailto:khan@xraylith.wisc.EDU ]
Sent: Tuesday, August 17, 1999 9:27 PM
To: pthreads-win32@sourceware.cygnus.com
Subject: gcc mingw/crtdll patch


This patch adds support for CRTDLL, and most of the changes have to do
with the difference between MSVCRT begin/endthreadex and CRTDLL
begin/endthread pair. MSDN docs do describe the differences, as well
as http://support.microsoft.com/support/kb/articles/q132/0/78.asp

The only issue is the support of thread function return code that
won't work with CRTDLL, and that's why pthread_join will always
stuff 0 in the return area. I've noted that in the join1 test as
well. This can be "fixed", but that'll take some actual work as 
opposed to these trivial changes.

With join1 tweaked, all tests pass.

Patch requires my last one.

Tue Aug 17 20:17:58 CDT 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* create.c (pthread_create): Add CRTDLL suppport.
	* exit.c (pthread_exit): Likewise.
 	* private.c (_pthread_threadStart): Likewise.
	(_pthread_threadDestroy): Likewise.
	* sync.c (pthread_join): Likewise.
	* tests/join1.c (main): Warn about partial support for CRTDLL.

Index: create.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/create.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 create.c
--- create.c	1999/08/17 00:50:05	1.1.1.1
+++ create.c	1999/08/18 01:09:41
@@ -125,6 +125,8 @@ pthread_create (pthread_t * tid,
     : PThreadStateSuspended;
 
   thread->keys = NULL;
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
+
   thread->threadH = (HANDLE)
     _beginthreadex (
 		     (void *) NULL,	/* No security info             */
@@ -133,6 +135,27 @@ pthread_create (pthread_t * tid,
 		     parms,
 		     (unsigned) run ? 0 : CREATE_SUSPENDED,
 		     (unsigned *) &(thread->thread));
+
+#else /* __MINGW32__ && ! __MSVCRT__ */
+
+  thread->threadH = (HANDLE)
+    _beginthread (
+		   (void (*) (void *)) _pthread_threadStart,
+		   (unsigned) stackSize,	/* default stack size   */
+		   parms);
+
+  /* Make the return code to match _beginthreadex's.  */
+  if (thread->threadH == (HANDLE)-1L)
+    thread->threadH = NULL;
+  else if (! run)
+    {
+      /* beginthread does not allow for create flags, so we do it now.
+         Note that beginthread itself creates the thread in SUSPENDED
+	 mode, and then calls ResumeThread to start it.  */
+      SuspendThread (thread->threadH);
+    }
+
+#endif /* __MINGW32__ && ! __MSVCRT__ */
 
   result = (thread->threadH != 0) ? 0 : EAGAIN;
 
Index: exit.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/exit.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 exit.c
--- exit.c	1999/08/17 00:50:05	1.1.1.1
+++ exit.c	1999/08/18 01:09:41
@@ -66,7 +66,11 @@ pthread_exit (void *value_ptr)
     {
       _pthread_callUserDestroyRoutines(self);
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
       _endthreadex ((unsigned) value_ptr);
+#else
+      _endthread ();
+#endif
       
       /* Never reached */
     }
@@ -99,7 +103,11 @@ pthread_exit (void *value_ptr)
 
       _pthread_callUserDestroyRoutines(self);
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
       _endthreadex ((unsigned) value_ptr);
+#else
+      _endthread ();
+#endif
 
 #endif /* __cplusplus */
 
Index: implement.h
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/implement.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 implement.h
--- implement.h	1999/08/18 01:08:12	1.2
+++ implement.h	1999/08/18 01:10:20
@@ -321,7 +321,12 @@ void _pthread_threadDestroy (pthread_t t
 
 void _pthread_cleanupStack (void);
 
-unsigned PT_STDCALL _pthread_threadStart (ThreadParms * threadParms);
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
+unsigned PT_STDCALL
+#else
+void
+#endif
+_pthread_threadStart (ThreadParms * threadParms);
 
 void _pthread_callUserDestroyRoutines (pthread_t thread);
 
Index: private.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/private.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 private.c
--- private.c	1999/08/18 01:08:12	1.2
+++ private.c	1999/08/18 01:12:23
@@ -159,7 +159,11 @@ ExceptionFilter (EXCEPTION_POINTERS * ep
 
 #endif /* _MSC_VER */
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
 unsigned PT_STDCALL
+#else
+void
+#endif
 _pthread_threadStart (ThreadParms * threadParms)
 {
   pthread_t self;
@@ -178,6 +182,11 @@ _pthread_threadStart (ThreadParms * thre
   start = threadParms->start;
   arg = threadParms->arg;
 
+#if defined (__MINGW32__) && ! defined (__MSVCRT__)
+  /* beginthread does not return the thread id, and so we do it here. */
+  self->thread = GetCurrentThreadId ();
+#endif
+
   free (threadParms);
 
   pthread_setspecific (_pthread_selfThreadKey, self);
@@ -270,12 +279,18 @@ _pthread_threadStart (ThreadParms * thre
 
   _pthread_callUserDestroyRoutines(self);
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
   _endthreadex ((unsigned) status);
+#else
+  _endthread ();
+#endif
 
   /*
    * Never reached.
    */
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
   return (unsigned) status;
+#endif
 
 }				/* _pthread_threadStart */
 
@@ -291,10 +306,13 @@ _pthread_threadDestroy (pthread_t thread
 	  CloseHandle (thread->cancelEvent);
 	}
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
+      /* See documentation for endthread vs endthreadex. */
       if( thread->threadH != 0 )
 	{
 	  CloseHandle( thread->threadH );
 	}
+#endif
 
       free (thread);
     }
Index: sync.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/sync.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 sync.c
--- sync.c	1999/08/17 00:50:05	1.1.1.1
+++ sync.c	1999/08/18 01:09:41
@@ -128,6 +128,8 @@ pthread_join (pthread_t thread, void **v
 
       stat = WaitForSingleObject (thread->threadH, INFINITE);
 
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
+
       if (stat == WAIT_OBJECT_0)
 	{
 	  if (value_ptr != NULL
@@ -148,6 +150,24 @@ pthread_join (pthread_t thread, void **v
 	{
 	  result = ESRCH;
 	}
+
+#else /* __MINGW32__ && ! __MSVCRT__ */
+
+      /* If using CRTDLL, the thread may have exited, and endthread
+	 will have closed the handle. Also, begin/endthread pair
+	 does not allow for a exit code -- we'll force it to be
+	 always 0.  */
+
+      if (value_ptr != NULL)
+	*((DWORD*)(value_ptr)) = 0;
+      
+      /*
+       * The result of making multiple simultaneous calls to
+       * pthread_join() specifying the same target is undefined.
+       */
+      _pthread_threadDestroy (thread);
+
+#endif /* __MINGW32__ && ! __MSVCRT__ */
     }
 
   return (result);
Index: tests/join1.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/pthreads/tests/join1.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 join1.c
--- tests/join1.c	1999/08/17 00:50:05	1.1.1.1
+++ tests/join1.c	1999/08/18 01:16:42
@@ -33,7 +33,12 @@ main(int argc, char * argv[])
 	for (i = 0; i < 4; i++)
 	  {
 	    assert(pthread_join(id[i], (void *) &result) == 0);
+#if ! defined (__MINGW32__) || defined (__MSVCRT__)
 	    assert(result == i);
+#else
+# warning pthread_join not fully supported in this configuration.
+	    assert(result == 0);
+#endif
 	  }
 
 	/* Success. */

Regards,
Mumit

Return values

[Milan Gardian]

> With regards to the return code not working...
> In my original contributed work, the pthread_t structure contained
> an unused attribute, "exitStatus" that can be used precisely for
> the purpose of implementing the return code.
>
> I didn't bother to use it since _endthreadex and GetExitCodeThread
> did the trick just fine for WIN32.
>
> However, if you need to use an alternative method, you simply can
> do the following:
>
> 1) pthread_exit - stuff the result in t->exitStatus.
> 2) In _pthread_threadStart (?) if the user's thread routine actually
>    returned, then stuff the return value in t->exitStatus.
> 3) In pthread_join, if the thread had terminated, simply extract
>    the exit status from the instance of the thread structure.
[SNIP]

I came across this "feature" of your pthread implementation some time ago
(and it is another reason why I don't trust your pthreads at all) - the
value returned by a thread function IS BEING IGNORED!!! I think every decent
implementation of threads should care about the value (void *) that si
returned by thread functions (why else would the pointer to thread function
be declared as "returning pointer to void", ha?). It is not the case of your
pthreads. Please take a look at:
---
file: pthreads/private.c
line: 192

Snip from the file, lines 187 to 194; Visual C++:
__try
{
  /*
   * Run the caller's routine;
   */
  (*start) (arg);
  status = (void *) 0;
}
---
CAN you please EXPLAIN why the hell have you done it this way? Is there a
reason? WHY do you set status value apriori to ZERO??? Why not
status = (*start) (arg);

Attached please find a simple program that tests return values (MSVC6
project) acquired by 'pthread_join' call. One thread (1) returns a value
directly using return statement, the other one (2) returns another value
using 'pthread_exit'. I have run it on both WinNT machine and UNIX machine.
Here are the outputs:

---
Platform: M$ WinNT 4, SP5
Compiler: M$ Visual C++ 6, no SP
pthreads: Pthreads-win32 snapshot 1999-08-12
- (output) -
Creating thread 1
Creating thread 2
Worker thread 1 running (returning 10)
Worker thread 2 running (returning 20)
Thread 1 returned 0
Thread 2 returned 20

Using Win32 'CreateThread' to create thread 1
Worker thread 1 running (returning 10)
Using Win32, thread 1 returned 10


---
Platform: DIGITAL UNIX V4.0 (Rev. 564)
Compiler: DIGITAL C++ V6.0-010
pthreads: Default DIGITAL pthreads
- (output) -
Creating thread 1
Creating thread 2
Worker thread 1 running (returning 10)
Worker thread 2 running (returning 20)
Thread 1 returned 10
Thread 2 returned 20
---

I have used the same "ReturnValue.cpp" file for both Win32 and UNIX version
of the compiled program (I used "cxx -g
ReturnValue.cpp -pthread -D__USE_STD_IOSTREAM" line to compile it in UNIX).
Please note that in your pthreads, join to thread 1 returns zero (and no
suprise...), while on UNIX it returns correct value -> you have a SERIOUS
FLAW in the BASIC functionality of pthreads (if somebody relies on return
values from threads (and not solving it with this NASTY pthread_exit)...
they are out of luck with your implementation).

Please take a look at this issue,
Best regards,
	Milan Gardian

Re: Return values

[Ross Johnson]

On Wed, 18 Aug 1999, Milan Gardian wrote:

> I came across this "feature" of your pthread implementation some time ago
> (and it is another reason why I don't trust your pthreads at all) - the
> value returned by a thread function IS BEING IGNORED!!! I think every decent
> implementation of threads should care about the value (void *) that si
> returned by thread functions (why else would the pointer to thread function
> be declared as "returning pointer to void", ha?). It is not the case of your
> pthreads. Please take a look at:
> ---
> file: pthreads/private.c
> line: 192
> 
> Snip from the file, lines 187 to 194; Visual C++:
> __try
> {
>   /*
>    * Run the caller's routine;
>    */
>   (*start) (arg);
>   status = (void *) 0;
> }
> ---
> CAN you please EXPLAIN why the hell have you done it this way? Is there a
> reason? WHY do you set status value apriori to ZERO??? Why not
> status = (*start) (arg);

Dear Milan,

Yes, this would appear to be an obvious bug. I'll make the change
and credit you with finding it. Perhaps it was a case of not seeing
the trees because the forest was in the way, as distinct from not
seeing the forest because the trees are in the way.

Thanks also for providing your test code, which I will add to the
test suite.

This is an active project and it relies heavily on people like
yourself using it in the real world and reporting problems. I hope
that as you look through the code you'll find that it is really a
very well conceived implementation of POSIX threads on top of Win32
threads.

Any other problems or suggestions for improvement will be more than
happily received.

Cheers.
Ross

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+

pthread_exit bug ?

[Tristan Savatier]

I am currently using pthreads-win32-snap-1999-05-30,
using VC++ 6.0 under Win98.

My program creates several threads.  At termination,
each thread (except the main thread) terminates by calling
pthread_exit, then the main thread terminates by
calling pthread_exit (at this point, all my threads
are terminated, therefore the process should disapear).

This works fine with native pthread libraries on
Linux and other Posix systems.

But I noticed that with pthreads-win32, calling pthread_exit 
to terminate my main thread does not work well: the process survives
with two dangling threads (both threads are some type
of internal kernel threads, not running any of my code).

If I call exit(0) [instead of pthread_exit] to terminate
my main thread, the process terminates properly (i.e.
this is a workaround).

This looks like a bug: the pthread standard says,
in the pthread_exit specification:
<<When the last thread in a process exits, exit(0)
will be called.>>

Is that a known bug ?

-t

Re: pthread_exit bug ?

[Peter Slacik]

Tristan Savatier wrote:

> I am currently using pthreads-win32-snap-1999-05-30,
> using VC++ 6.0 under Win98.
>
> My program creates several threads.  At termination,
> each thread (except the main thread) terminates by calling
> pthread_exit, then the main thread terminates by
> calling pthread_exit (at this point, all my threads
> are terminated, therefore the process should disapear).
>
> This works fine with native pthread libraries on
> Linux and other Posix systems.
>
> But I noticed that with pthreads-win32, calling pthread_exit
> to terminate my main thread does not work well: the process survives
> with two dangling threads (both threads are some type
> of internal kernel threads, not running any of my code).
>
> If I call exit(0) [instead of pthread_exit] to terminate
> my main thread, the process terminates properly (i.e.
> this is a workaround).
>
> This looks like a bug: the pthread standard says,
> in the pthread_exit specification:
> <<When the last thread in a process exits, exit(0)
> will be called.>>
>
> Is that a known bug ?

Yes, I noticed this already and tried to find out possible workarounds, but
I forgot this problem later, because my application calls exit().

I'm not sure but I remember that last year's snapshots behaved correctly...

Peter Slacik

Re: pthread_exit bug ?

[Ross Johnson]

Tristan,

Please try pthreads-win32-snap-1999-08-12 with your code. It fixes a
bug in pthread_exit.

ftp://sourceware.cygnus.com/pub/pthreads-win32/dll-latest

I'm about to create a new snapshot so keep a lookout for that one
also.

Cheers.
Ross 

On Thu, 2 Sep 1999, Tristan Savatier wrote:

> I am currently using pthreads-win32-snap-1999-05-30,
> using VC++ 6.0 under Win98.
> 
> My program creates several threads.  At termination,
> each thread (except the main thread) terminates by calling
> pthread_exit, then the main thread terminates by
> calling pthread_exit (at this point, all my threads
> are terminated, therefore the process should disapear).
> 
> This works fine with native pthread libraries on
> Linux and other Posix systems.
> 
> But I noticed that with pthreads-win32, calling pthread_exit 
> to terminate my main thread does not work well: the process survives
> with two dangling threads (both threads are some type
> of internal kernel threads, not running any of my code).
> 
> If I call exit(0) [instead of pthread_exit] to terminate
> my main thread, the process terminates properly (i.e.
> this is a workaround).
> 
> This looks like a bug: the pthread standard says,
> in the pthread_exit specification:
> <<When the last thread in a process exits, exit(0)
> will be called.>>
> 
> Is that a known bug ?
> 
> -t
> 

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+

RE: pthread_exit bug ?

[Milan Gardian]

[snip]
> My program creates several threads.  At termination,
> each thread (except the main thread) terminates by calling
> pthread_exit, then the main thread terminates by
> calling pthread_exit (at this point, all my threads
> are terminated, therefore the process should disapear).

(This note does not try to diminish the meaning of the reported bug)
Q: Is there a reason to use pthread_exit from the main thread? A special
functionality prehaps? Specifically, I would like to know if there's some
difference between these two code snips:

(a)
int main(void)
{
    //Do some threading stuff...
    return (24);
}


(b)
void main(void)
{
    //Do some threading stuff...
    pthread_exit(24);
}

From the rather ideological reasons  :) I prefer the (a) version, but will
gladly learn if there's a point in the (b) version.

Looking forward to anyone answering;
Yours sincerely,
	Milan G.

Re: [pthread-win32] RE: pthread_exit bug ?

[Tristan Savatier]

Milan Gardian wrote:
> 
> [snip]
> > My program creates several threads.  At termination,
> > each thread (except the main thread) terminates by calling
> > pthread_exit, then the main thread terminates by
> > calling pthread_exit (at this point, all my threads
> > are terminated, therefore the process should disapear).
> 
> (This note does not try to diminish the meaning of the reported bug)
> Q: Is there a reason to use pthread_exit from the main thread? A special
> functionality prehaps? Specifically, I would like to know if there's some
> difference between these two code snips:
> 
> (a)
> int main(void)
> {
>     //Do some threading stuff...
>     return (24);
> }

most of the time it is not practical to return from
main().  this is why the exit() routine was invented.
you can call exit() from some other routine called
directly or indirectly by main().

So the question becomes: is there any difference between

(a')
int main(void)
{
    //Do some threading stuff...
    exit (24);
}

and...

> 
> (b)
> void main(void)
> {
>     //Do some threading stuff...
>     pthread_exit(24);
> }

According to my book "Multithreaded
Programming with PThread" by Bil Lewis and Daniel J.Berg,
yes, there is a difference: they write that if the last thread
calls pthread_exit(n), then exit(0) is called (regardless
of n).

(b) is therefore equivalent to

int main(void)
{
    //Do some threading stuff...
    exit (0);
    ^^^^^^^^
}


> 
> >From the rather ideological reasons  :) I prefer the (a) version, but will
> gladly learn if there's a point in the (b) version.

Again, I don't know if the authors of my book are write, and I do not
have the official pthread standard documents.

-t

Re: [pthread-win32] RE: pthread_exit bug ?

[Tristan Savatier]

Milan Gardian wrote:
> 
> [snip]
> > My program creates several threads.  At termination,
> > each thread (except the main thread) terminates by calling
> > pthread_exit, then the main thread terminates by
> > calling pthread_exit (at this point, all my threads
> > are terminated, therefore the process should disapear).
> 
> (This note does not try to diminish the meaning of the reported bug)
> Q: Is there a reason to use pthread_exit from the main thread? A special
> functionality prehaps? Specifically, I would like to know if there's some
> difference between these two code snips:
> 
> (a)
> int main(void)
> {
>     //Do some threading stuff...
>     return (24);
> }
> 
> (b)
> void main(void)
> {
>     //Do some threading stuff...
>     pthread_exit(24);
> }

Note also another big difference between those two cases,
according to my book:

When main() "falls off the bottom" i.e. returns,
the main thread makes an implicit call to exit(),
also killing the process.

When any other thread "falls off the bottom" of its
initial function, it implicitely calls pthread_exit()
exiting only that one thrad.

In the special case where the main thread calls pthread_exit(),
that thread exits but does NOT call exit(), and the
process continues.

Finally, if all the [main and user-created] threads exit,
the thread library will detect that and call exit() itself
to terminate the process.

-t

RE: pthread_exit bug ?

[Bossom, John]

Yes... Unless you call pthread_exit from the main line, you will
not have any of your thread-specific-destroy routines called for the
main-line.

(I believe this is documented in one of the PThreads books by Bil Lewis)


John.

-----Original Message-----
From: Milan Gardian [ mailto:mg@tatramed.sk ]
Sent: Thursday, September 02, 1999 6:36 AM
To: 'Tristan Savatier'; pthreads-win32@sourceware.cygnus.com
Subject: RE: pthread_exit bug ?


[snip]
> My program creates several threads.  At termination,
> each thread (except the main thread) terminates by calling
> pthread_exit, then the main thread terminates by
> calling pthread_exit (at this point, all my threads
> are terminated, therefore the process should disapear).

(This note does not try to diminish the meaning of the reported bug)
Q: Is there a reason to use pthread_exit from the main thread? A special
functionality prehaps? Specifically, I would like to know if there's some
difference between these two code snips:

(a)
int main(void)
{
    //Do some threading stuff...
    return (24);
}


(b)
void main(void)
{
    //Do some threading stuff...
    pthread_exit(24);
}

From the rather ideological reasons  :) I prefer the (a) version, but will
gladly learn if there's a point in the (b) version.

Looking forward to anyone answering;
Yours sincerely,
	Milan G.