RE: Return values

RE: Return values

[Bossom, John]

Dear Milan,

First of all, thank you for finding a flaw in the implementation.
I am sure that Ross will duely note your contribution
and make the appropriate change.

However, I am quite offended by your method and
tone of reporting a problem. Your level of maturity 
and professionalism in communicating with other people
leaves much to be desired.

John.


-----Original Message-----
From: Milan Gardian [ mailto:mg@tatramed.sk ]
Sent: Wednesday, August 18, 1999 7:41 AM
To: John.Bossom@cognos.com; rpj@ise.canberra.edu.au
Cc: pthreads-win32@sourceware.cygnus.com
Subject: Return values


> 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

[Hujsak, Jonathan T]

Ross, 

That was a amazingly diplomatic response. The flames from
that post almost melted my inbox. It's hard for anyone to
imagine that such an oversight would have been intentional 
given the implicit difficulty of developing pthreads on 
win32 in the first place (most threading experts I work 
with insisted it could not be done). There is hope for NT 
yet.

We continue to use your work with great success.

--Jon Hujsak/Marconi Integrated Systems

-----Original Message-----
From: Ross Johnson [ mailto:rpj@ise.canberra.edu.au ]
Sent: Wednesday, August 18, 1999 9:31 PM
To: Milan Gardian
Cc: John.Bossom@Cognos.COM; pthreads-win32@sourceware.cygnus.com
Subject: Re: Return values


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                |
+--------------------------+

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                |
+--------------------------+

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