Hello, On Thu, 11 Dec 2008 03:04:32 +0100, Mike Frysinger <[email protected]> wrote:
> 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. It is going to randomly change when new client connection arises. > if the func never returns (or it does some > sort of > locking/communication with child threads so the info is properly > passed), then Yes, but the condition should be (AND it does some sort of locking...) > there is no problem whatsoever with using stack storage. If you're talking about 1) there's no problem with stack storage. Global or dynamic storage would have just the same problems. > 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". Yes, something like that - although I'd expect it more in ANSI C standard and not that direct. > 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. OK, I'll resubmit. Regards Jiri Palecek -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------------------------------------------------------ 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
