This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

pthreads comments and suggestions [was: Re: Handle leak ?]


David Baggett wrote:
> 
> Yup, I spent two weeks trying to track this down.
> 
> There's a bug in the current code (unless it has been fixed in the last
> month or so) that causes not only the handle leakage you're seeing,
> but alsoinfrequent crashes. The relevant code is in dll.c:
> 
> /*
>  * Detached threads have their resources automatically
>  * cleaned up upon exit (others must be 'joined'
>  */
> if (self != NULL && self->detachState == PTHREAD_CREATE_DETACHED) {
>     if (self->threadH) {
>         pthread_setspecific (_pthread_selfThreadKey, NULL);
>         _pthread_threadDestroy (self);
>     }
> }

If you look in _pthread_threadDestroy (in private.c), you'll see that
there is already a guard against the case where threadH == 0.

In fact this guard looks un-necessary:
if I look in create.c, I don't see any situation where
thread->threadH can be 0.  If it was zero, then pthread_create
would return EAGAIN (of course there is no way to really
know why there was an error...). thread->threadH = 0 means
that the thread structure has been trashed...

By the way, I think that it would be a good idea to create
a TSD variable in which pthread routines would store
the Win32 error code indicating the reason of the most
recent failure.  A special routine, say GetLastPthreadError(),
could be called to get this win32 error code.

So if I call a pthread function and get some meaningless UNIX
error code (e.g. pthread_create returns EAGAIN), there would be
a way to know what is the real error.

Also, it would be nice if there was a routine to get the win32
thread handle from the pthread_t id.  In certain cases, even
though we use pthread_win32, we want to refine the control
the we have on threads.

For example, on Windows-CE 3.0, it is possible to set the
thread quantum with CeSetThreadQuantum().  But for that we
need the thread handle.  It is easy to get if for the
current thread (with GetCurrentThread()), but there is no
way to get it for another thread if we only know the
pthread id...

-t

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]