[phobos] std.process and std.datetime - circular dependency on OSX

[Brad Roberts]

On Mon, 3 Oct 2011, Sean Kelly wrote:

> On Oct 1, 2011, at 9:07 PM, Jonathan M Davis wrote:
> 
> > On Saturday, October 01, 2011 20:34:45 Jonathan M Davis wrote:
> >> On Friday, September 30, 2011 20:16:33 Walter Bright wrote:
> >>> Both have static constructors. This wasn't detected before because of a
> >>> bug in dmd (now fixed).
> >> 
> >> std.process doesn't even import std.datetime, so I don't know why a circular
> >> dependency would even exist in this case. As usual, trying to figure out
> >> what's really going on with a circular dependency isn't going to be fun.
> > 
> > Ah. It looks like it's happening because std.exception uses std.datetime in 
> > its unit tests. Well, hopefully the same trick that std.file and std.stdio use 
> > should work with std.process as well. It would be really nice though to be 
> > able to just somehow mark one or both of the static constructors or modules to 
> > indicate that the initialization order doesn't matter (or to tell it which 
> > order to use if that's a better solution). I'll have a pull request with an 
> > attempted solution up shortly, but someone with a Mac is going to have to test 
> > it.
> 
> Seems like yet another reason to put complex unit tests in their own 
> module.  And this was all for an alias of getpid that maps to functions 
> in both Posix and Win32?  Is that even a good idea to begin with?  And 
> why move the alias to core.thread?  It's not like threads have anything 
> to do with processes or process IDs.  Was this meant to be a quick fix 
> so we could run again or a permanent fix?

This was but one about a half dozen causes of loops.  Most of the rest 
were easier to fix (drop unnecessary imports, primarily of std.stdio).  
The (hopefully) last one will require some additional refactoring to 
break.  Only one of them involved the unittests, so let's remove that red 
herring from this thread.

I thought about introducing a core.process file, but that would have been 
even more dubious for just that pair of aliases and isn't something I felt 
confortable doing without a longer consultation cycle.

As to the permanency of it, nothing is ever permanent when it comes to 
code.  I'm all for a better home should one be found.  That said, the 
distinction between a process and a thread is a fairly narrow one so I 
don't consider it a particularly _bad_ fit either.  It's about the same 
delta as thread to fibre, imho.