On Wednesday 10 December 2008 20:17:23 Jiří Paleček wrote:
> 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.the behavior you describe here is semantically correct. whether the resulting code operates as the guy writing it intended is a different issue. the storage for fd isnt going anywhere until the function returns, nor is it just going to randomly change. if the func never returns (or it does some sort of locking/communication with child threads so the info is properly passed), then there is no problem whatsoever with using stack storage. and in this case, i'd be pretty surprised if POSIX didnt say anything -- something along the lines of "a portable application cannot rely on the behavior of stack storage after a function returns". i'd be curious about thread local storage -- both in terms of actual behavior an POSIX defined behavior ... however, back to the original issue ... i'm not suggesting the tests in question are doing the right thing, or your patch is wrong, just that your original explanation is bogus. feel free to resubmit the patch with a correct explanation (pointing out that the previous change of passing-by-value to passing-by-reference is wrong because the variable is on the stack and changed for different threads). committing a correct patch with a very misleading/wrong changelog is almost as bad as having broken code in the first place. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
