Web lists-archives.com

Re: [Mingw-users] GCC-4.9.3 is now our current release




Hard finding much info about why they decided to use a struct,
but i managed to dig up a really old thread on google about it.

> Originally pthread_t was defined as a pointer (to the opaque pthread_t_
> struct) and later it was changed to a struct containing the original
> pointer plus a sequence counter. This is allowed under both the original
> POSIX Threads Standard and the current Single Unix Specification.
>
> When pthread_t is a simple pointer to a struct some very difficult to
> debug problems arise from the process of freeing and later allocing
> thread structs because new pthread_t handles can acquire the identity of
> previously detached threads. The change to a struct was made, along with
> some changes to their internal managment, in order to guarantee (for
> practical applications) that the pthread_t handle will be unique over the
> life of the running process.
>
> Where application code attempts to compare one pthread_t against another
> directly, a compiler error will be emitted because structs can't be
> compared at that level. This should signal a potentially serious problem
> in the code design, which would go undetected if pthread_t was a scalar.
>
> The POSIX Threading API provides a function named pthread_equal() to
> compare pthread_t thread handles.
>
> Other pthreads implementations, such as Sun's, use an int as the handle
> but do guarantee uniqueness within the process scope. Win32 scalar typed
> thread handles also guarantee uniqueness in system scope. It wasn't clear
> how well the internal management of these handles would scale as the
> number of threads and the fragmentation of the sequence numbering
> increased for applications where thousands or millions of threads are
> created and detached over time. The current management of threads within
> pthreads-win32 using structs for pthread_t, and reusing without ever
> freeing them, reduces the management time overheads to a constant, which
> could be important given that pthreads-win32 threads are built on top of
> Win32 threads and will therefore include that management overhead on top
> of their own. The cost is that the memory resources used for thread
> handles will remain at the peak level until the process exits.
>
> While it may be inconvenient for developers to be forced away from making
> assumptions about the internals of pthread_t, the advantage for the
> future development of pthread-win32, as well as those applications that
> use it and other pthread implementations, is that the library is free to
> change pthread_t internals and management as better methods arise.


so it seems the .p pointer is actually correct as pr the description p 
is the original pointer from back before they changed it.

I think i can close the book on it now :) but was nice to have 
confirmation before we start rolling it out.

Thanks for your help.

Regards Ralph Engels

Den 18-03-2016 kl. 04:27 skrev K. Frank:
> Hello Ralph!
>
> On Thu, Mar 17, 2016 at 10:29 PM, ralph engels <ralphengels@xxxxxxxxx> wrote:
>> Ok one bug it seems
>>
>>    __gthread_objc_thread_id (void)
>>    {
>>      if (__gthread_active_p ())
>> +#ifdef PTW32_VERSION
>> +    return (objc_thread_t) __gthrw_(pthread_self) ().x; // was pointer
>> to handle needs to be pointer to scalar
>> ...
> Let me start with my standard disclaimer that I know nothing about
> objective-c.
>
> But this seems fishy to me.
>
> I assume that pthread_self returns a pthread_t, which is:
>
>     typedef struct {
>         void * p;                   /* Pointer to actual object */
>         unsigned int x;             /* Extra information - reuse count etc */
>     } ptw32_handle_t;
>
> I find it hard to believe that the __gthread_objc_thread_id should
> be the x member ("Extra information - reuse count etc").  That
> doesn't seem to be a very plausible thread id.  The p member
> ("Pointer to actual object") I could believe could serve as a thread
> id.
>
> That still leaves the question as to why pthreads wants to use
> the whole structure -- both the p and x members together -- as the
> thread id, but maybe p alone is good enough.  But x alone seems
> unlikely to be able to act as a unique identifier for a specific thread,
> objective-c, or not.
>
> Again, just guesswork on my part, but using x alone does seem
> fishy.
>
>
> Best.
>
>
> K. Frank
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@xxxxxxxxxxxxxxxxxxxxx
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe