Boost-Commit :

Date view	Thread view	Subject view	Author view

From: bdawes_at_[hidden]
Date: 2007-10-11 20:23:33

Author: bemandawes
Date: 2007-10-11 20:23:33 EDT (Thu, 11 Oct 2007)
New Revision: 39954
URL: http://svn.boost.org/trac/boost/changeset/39954

Log:
Converted to HTML
Added:
sandbox/committee/LWG/Pete_comments.html (contents, props changed)

Added: sandbox/committee/LWG/Pete_comments.html
==============================================================================
--- (empty file)
+++ sandbox/committee/LWG/Pete_comments.html 2007-10-11 20:23:33 EDT (Thu, 11 Oct 2007)
@@ -0,0 +1,119 @@
+<html>
+
+<head>
+<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
+<meta name="ProgId" content="FrontPage.Editor.Document">
+<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
+<title>This is much better</title>
+</head>
+
+<body>
+
+✔ This is much better, but it's still in draft stage, not ready yet for voting
+into the WD. Comments:
+<ol>
+ <li>the description of the meaning of thread::id is distributed among several
+ different clauses, and it's hard to figure out just what it means. 
+ </li>
+ <li>the description of thread::native_handle_type and native_handle() is so
+ vague (appropriately so) that it might be better to leave it out completely.
+ Since you can't do anything meaningful with it if it's present, just leave it
+ up to the implementation to tell you what it supports and what you can do with
+ it. Same thing applies to the corresponding things in the other classes. If it
+ stays in, it's overconstrained. In particular, if it's copyable, this requires
+ copying it to pass it to the OS, even if the OS takes a pointer to that
+ object. Just leave it to the implementation to match what the OS requires. 
+ </li>
+ <li>objects of type thread::id "uniquely identify" threads of execution.
+ Except that they don't, because default-constructed objects compare equal, and
+ the id returned from a thread that is not joinable also compares equal to a
+ default-constructed object. 
+ </li>
+ <li>thread::get_id() for a default-constructed thread returns an object that
+ refers to "not any thread". That last term isn't used anywhere else, so
+ shouldn't be used. 
+ </li>
+ <li>default constructor for thread constructs an object that is not "attached"
+ to any thread; other constructors create objects that "represent" a thread.
+ Assignment operator talks about an object that "refers" to a thread. 
+ </li>
+ <li>template constructor for thread: "if f is an rvalue, F must only be
+ MoveConstructible". Does this mean that F must not be CopyConstructible? 
+ </li>
+ <li>thread::join "may throw system_error". Under what circumstances? 
+ </li>
+ <li>call_once: "F is CopyConstructible", but F is not defined. 
+ </li>
+ <li>Mutex concepts: mutex type is required to be Destructible, so requirement
+ that its destructor not exit by an exception is redundant. 
+ </li>
+ <li>"If and only if the mutex type ...", followed by "If there is no ..."
+ which is the obverse. Either use iff and only if, or use if ... else. 
+ </li>
+ <li>"Implementations may supply additional ..." is entirely redundant. 
+ </li>
+ <li>"The class mutex is a ...", but "The class recursive_mutex shall be a
+ ...". 
+ </li>
+ <li>Timed Mutexes: "The type TimeDuration provides resolution information..."
+ doesn't sound like a precondition, but an informative description. To the
+ extent that it's actually a precondition, it's a little fuzzy whether it only
+ applies to non-recursive mutexes. 
+ </li>
+ <li>Timed Mutexes, Effects needs tightening. 
+ </li>
+ <li>Class lock_guard: what does "Mutex ownership cannot be deferred" mean? 
+ </li>
+ <li>lock_guard, precondition: what does it mean for the lifetime of an object
+ to be greater than the lifetime of another object? Further, it can't be a
+ precondition that the mutex still be in existence after the call, since that's
+ not "pre" (i.e. there's no way to test this condition on entry into the
+ function). 
+ </li>
+ <li>unique_lock constructors: constructors that take mutex say that the object
+ stores a reference to the passed mutex; what does that reference refer to
+ after default construction? 
+ </li>
+ <li>unique_lock move constructor "transfers mutex ownership". What does this
+ mean? 
+ </li>
+ <li>unique_lock::timed_lock: describes handling when the resolution of
+ TimeDuration is greater than the native resolution; seems like this belongs in
+ the description of mutex lock, not in this forwarder. 
+ </li>
+ <li>unique_lock::unspecified-bool-type: returns null or non-null. Seems to be
+ assuming (or imposing) constraints on the type returned. 
+ </li>
+ <li>unique_lock assignment operator: what is the "lock count" of a recursive
+ mutex? 
+ </li>
+ <li>generic locking algorithms: is there a requirement that the locks be
+ attempted in any particular order? 
+ </li>
+ <li>generic locking algorithms, lock: what does "an algorithm that avoids
+ deadlocks" mean? What, exactly, is required? 
+ </li>
+ <li>condition_variable::wait: "... unless lock refers to the same underlying
+ mutex object." Same as what? 
+ </li>
+ <li>condition_variable::wait, effects: "If the wait should throw an
+ exception..." probably should be "If the wait throws an exception...". "for
+ any reason" is redundant. "This thread of execution shall unblock ..." is part
+ of the effects of notify and notify_all, not of wait. 
+ </li>
+ <li>condition_variable::wait, throws: can throw only if a precondition is not
+ met? What if the system returns an error? 
+ </li>
+ <li>condition_variable::wait(lock, pred): what are the constraints on the type
+ Predicate? 
+ </li>
+ <li>condition_variable::timed_wait: the requirement that the function return
+ false if the time elapses means that when a blocked thread is released by
+ notify, the release code must check whether the time has elapsed, since the
+ timeout may not have been noticed earlier. Is this intentional? Seems more
+ useful to allow it to return true in this case.</li>
+</ol>
+
+</body>
+
+</html>
\ No newline at end of file

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk