std.parallelism: Request for Review

Jonathan M Davis jmdavisProg at gmx.com
Mon Feb 28 08:35:21 PST 2011


On Monday 28 February 2011 06:39:02 dsimcha wrote:
> On 2/28/2011 7:22 AM, Don wrote:
> > Russel Winder wrote:
> >> I accept your argument about core.cpuid and so will not investigate it
> >> further, other than to say it needs to work on 64-bit processors as well
> >> as 32-bit ones. The campaign now must be to have an OS query capability
> >> to find the number of processors.
> > 
> > Yes, it definitely needs to be a priority. It's a fundamental function
> > for a modern system programming language.
> > 
> > I'm not sure where this stuff should go, probably not into core.cpuid.
> > I could imagine something with a name like std.sysinfo, which dealt with
> > system configuration, and also provided OS-independent abstractions for
> > things like setting process affinity.
> > I think it should go into std.parallelism for now.
> 
> Done.  This was actually much easier than I thought.  I didn't
> document/expose it, though, because I didn't put any thought into
> creating an API for it.  I just implemented the bare minimum to make
> std.parallelism work properly.
> 
> https://github.com/dsimcha/std.parallelism/commit/db7751ba436af3f7ffcaa1b65
> 070f3981a75f98a
> 
> This code is tested (at least on my hardware) on Windows 7 and Ubuntu
> 10.10 in both 32 and 64 mode.  I did not test on Mac OS because I don't
> own any such hardware, though it **should** work because Mac OS is also
> POSIX.  Someone please confirm.
> 
> BTW, I don't imagine we care about supporting ancient (pre-Windows 2000)
> Windows.  The Windows code will only work for Win2k and up.

I think that we care enough that if it can easily be done work on pre-Win2k, 
then we might as well do so, but if we can't we can't. I believe that there's at 
least on example of something druntime or Phobos where something was done the 
way it was because it worked on pre-Win2k that way (though I can't recall where 
that code is at the moment). However, some of std.datetime wouldn't work pre-
Win2k, because the system calls that it makes didn't exist pre-Win2k, and there 
isn't a way around that. On the other hand, std.datetime.WindowsTimeZone could 
have been improved with regards to DST if it were to assume Vista or later, but 
we obviously can't do that.

At this point, I think that we need to assume that Phobos needs to work with XP 
and later for sure - and maybe Win2k (though I don't get the impression that 
Microsoft added much in the way of system calls with XP anyway) - but versions 
prior to that are supported only if we can reasonably do so. Some things just 
plain require Win2k or newer, and I think that for the most part it's reasonable 
to require Win2k or newer at this point.

- Jonathan M Davis


More information about the Digitalmars-d mailing list