Re: cluts daily reports 8/12 - continuing pthread_eintr, still stuck with alloc

["Luka Marčetić" <paxcoder@gmail.com>]

On 08/12/2011 05:39 PM, Rich Felker wrote:
> On Fri, Aug 12, 2011 at 05:40:26PM +0200, Luka Marčetić wrote:
>>>> Both musl and glibc macros generate invalid code for this one, it
>>>> ends with `do {;` in both cases iirc. Strange - what is it?
>>> You might want to read this:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cleanup_pop.html
>>>
>>> There's even a sample implementation in the rationale.
>>>
>>> Rich
>> What I read was:
>>
>> "The thread exits (that is, calls/pthread_exit/()<http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_exit.html>)."
>>
>> Then I clicked the link(http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_exit.html<http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_exit.html>),
>> hoping to find this:
>>
>> "An implicit call to/pthread_exit/() is made when a thread other
>> than the thread in which/main/() was first invoked returns from the
>> start routine that was used to create it."
>>
>> And when I did, I've overlooked '{', expecting an '}'. I regard this
>> as slight inconsistency in the standard. At least it's missing the
>> word "explicitly", but I'd reword it altogether hehe.
>> Anyway, I'll just cast the void* to a function pointer and call it directly.
> I don't follow what you're saying in this email...
>
> Rich

pthread_exit is allegedly called upon main thread function return, and 
it is specified to pop and execute pushed functions. I expected this to 
happen. I was blaming the spec for not being more specific, and saying 
that pthread_exit should be explicitly called. But in reality, perhaps 
even an implicit call should work, in which case the spec isn't to 
blame, but both implementations instead?
Luka