On Thu, 11 Dec 2008 01:13:42 +0100, Mike Frysinger <[EMAIL PROTECTED]>
wrote:
> On Wednesday 10 December 2008 17:15:01 Jiří Paleček wrote:
>> The problems are of those types:
>>
>> 1) Calling
>>
>> pthread_create(&th, &newattr, (void *)&new_thread, (void
>> *)&newsockfd)
>>
>> is wrong if eg. newsockfd is a variable subsequently modified by the
>> parent thread.
>>
>> 2) Calling
>>
>> pthread_exit((void *)&exit_val);
>>
>> is wrong if exit_val is a local or thread-local variable, incl.
>> errno.
>
> neither of these statements sounds correct. do you have a reference in
> the
> POSIX spec that backs up either of these ?
No, I didn't base these on POSIX, even though it would be probably
undefined under POSIX - the first because of a race (parent writes/child
reads) the second because of subsequent access to nonexistent value.
The problem with 1) is not POSIX violation, even if it POSIX defined that
behaviour to be defined-yet-unspecified (as concurrent accesses to C++
atomics), it would still have bad semantics - as in this code
while(true) {
fd = accept(...);
pthread_create(&th, &newattr, (void *)&new_thread, (void*)&fd))
}
it is unspecified whether every connection gets its (no more than one)
thread, which is not what we want.
In 2) you are passing pointer to a variable that will not exist after the
call to thread_exit to the joining thread (ie. thread calling thread_join)
- which means undefined behaviour when the joining thread tries to read
the variable.
Regards
Jiri Palecek
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
