Application Programming errors hidden by pthreads library

[reentrant <reentrant at yahoo dot com>]

I just joined the list, so forgive me if this has been discussed prior.  Is
there an archive of this mailing list publically available somewhere?


I've run into an oddity in the pthread library.  After many hours debugging
extremely mysterious behavior of my application I discovered that the pthread
library catches all exceptions that a thread entry point function could throw
(which on NT also includes Access Violations and such).

The result of the pthread library catching exceptions that it did not throw is
to mask and hide programming errors in the application using the pthread
library.  It's also inconsistent with the behavior of all other pthread
implementations I've worked with.  None of them catch any exceptions they
didn't throw (nor hide access violations, but of course I don't know of a Unix
where an access violation IS an exception).

For instance, if I call pthread_create with function EntryPoint, and some
function that EntryPoint calls throws an exception that it is not caught (a
programming error), the C++ standard says that the function terminate() should
be called.  Instead, the pthread library happily catches all exceptions, and
silently stops the thread.  So the behavior I see as a programmer is instead of
"abnormal program termination" I see my thread mysteriously stopped for no
apparent reason!

Also, even worse if I call pthread_create with function EntryPoint, and some
function it calls has an Access Violation, obviously the program should
"crash."
But again, as a programmer I see my thread mysteriously stopped for no apparent
reason and have no idea that the reason is because an access violation
occurred!


To avoid the above mentioned pitfalls of catch( ... ) (and the equivalent when
using __except in MSVC) I suggest never using catch( ... ) in the pthread
library at all, and if you absolutely must, rethrow the exception at the bottom
of the catch block with a "throw;" or in the case of __except to do the
equivalent of a rethrow returning EXCEPTION_CONTINUE_SEARCH instead of 
EXCEPTION_EXECUTE_HANDLER.

Granted there are times when all uncaught exceptions are desired to be caught,
and even access violations trapped, but that's the responsibility of the
application, not the pthread library.

For reference I include private.c where I implemented this in one case in the
pthread library (and there are a few others that also need attention).

Other than this oddity, I must admit that my experience has been that the
quality and functionality of this library is stellar.  Every contributor
deserves a pats on the back.  Excellent work.  I can't express my gratitude and
respect with mere words!

Dave


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

private.c