On Thu, 01 May 2014 10:42:54 -0400 Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thu, 01 May 2014 00:49:53 -0400, Jonathan M Davis via > Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > > On Wed, 30 Apr 2014 20:33:06 -0400 > > Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> > > wrote: > I do think there should be a way to mark a unit test as "don't > parallelize this". Regardless what our exact solution is, a key thing is that we need to be able have both tests which are run in parallel and tests which are run in serial. Switching to parallel by default will break code, but that may be acceptable. And I'm somewhat concerned about automatically parallelizing unit tests which aren't pure just because it's still trivial to write unittest blocks that aren't safely parallelizable (even if most such examples typically aren't good practice) whereas they'd work just fine now. But ultimately, my main concern is that we not enforce that all unit tests be parallelized, because that precludes certain types of tests. > A function may be impure, but run in a pure way. True. The idea behind using purity is that it guarantees that the unittest blocks would be safely parallelizable. But even if we were to go with purity, that doesn't preclude having some way to mark a unittest as parallelizable in spite of its lack of purity. It just wouldn't be automatic. > Anything that requires using the local time zone should be done in a > single unit test. Most everything in std.datetime should use a > defined time zone instead of local time. Because LocalTime is the default timezone, most of the tests use it. In general, I think that that's fine and desirable, because LocalTime is what most everyone is going to be using. Where I think that it actually ends up being a problem (and will eventually necessitate that I rewrite a number of the tests - possibly most of them) is when tests end up making assumptions that can break in certain time zones. So, in the long run, I expect that far fewer tests will use LocalTime than is currently the case, but I don't think that I agree that it should be avoided on quite the level that you seem to. It is on my todo list though to go over std.datetime's unit tests and make it stop using LocalTime where that will result in the tests failing in some time zones. > Take for example, std.datetime. The constructor for SysTime has this > line in it: > > _timezone = tz is null ? LocalTime() : tz; > > All unit tests that pass in a specific tz (such as UTC) could be > pure calls. But because of that line, they can't be! Pretty much nothing involving SysTime is pure, because adjTime can't be pure, because LocalTime's conversion functions can't be pure, because it calls the system's functions to do the conversions. So, very few of SysTime's unit tests could be parallelized based on purity. The constructor is just one of many places where SysTime can't be pure. So, it's an example of the types of tests that would have to be marked as explicitly parallelizable if we used purity as a means of determining automatic parallelizabitily. - Jonathan M Davis
