RE: Return values

["Hujsak, Jonathan T" <Jonathan.Hujsak@marconi-is.com>]

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