Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 13 Aug 2011 20:49:43 +0200
From: Luka Marčetić <>
Subject: Re: cluts daily reports 8/12 - continuing pthread_eintr, still
 stuck with alloc

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:
>>> There's even a sample implementation in the rationale.
>>> Rich
>> What I read was:
>> "The thread exits (that is, calls/pthread_exit/()<>)."
>> Then I clicked the link(<>),
>> 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?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.