std.log version 2

[Jonathan M Davis]

On 2011-06-05 10:24, Jose Armando Garcia wrote:
> The problem is that std.log is using the UTC() (indirectly) in shared
> static this() for the module. At that point the static ctr for UTC
> didn't get to execute. I first changed std.datetime to instantiate UTC
> in a shared static ctr for UTC but that still didn't work (I assume
> that is a bug in dmd). So I had to move the instantiation to a share
> static ctr for the module.
> 
> In my branch the follow code doesn't assert. Note that I was selfish
> and only fixed UTC but std.datetime has this problem in all the
> singletons.
> 
> import std.datetime;
> 
> shared static this()
> {
>    assert(UTC() !is null); // this is with my fix.
>    assert(LocalTime() is null); // I didn't fix LocalTime!
> }
> 
> Having said that what is D's idiom/recommended way of constructing
> singletons? Maybe phobos should create shared/global singleton with
> the following idiom:
> 
> shared(T) singleton(T)() if(is(T == class))
> {
>    shared static T one;
>    if(one is null) cas(&one, null, new shared(T));
> 
>    return one;
> }

Phobos has no idiom or policies for dealing with singletons. In, fact I think 
that std.datetime is probably the only module that even has any at this point 
(most Phobos modules have functions primarily rather than types which may or 
may not be singletons).

In this particular case, because the singletons are immutable, changing them 
to shared makes a lot of sense, but in the general case, it probably wouldn't 
(at which point it would be a singleton per thread rather than globally). So, 
I'll take a look at making the approriate changes in std.datetime for all of 
its singletons.

But if you could, I'd really appreciate it if you could create a small test 
case (which has nothing to do with std.datetime), which shows the bug with 
regards to the shared module constructor, since that needs to be fixed. Having 
to move the variable into the module's scope like that is ugly and shouldn't 
be necessary at all. I guess that std.datetime will be stuck for the moment, 
but the bug does need to be properly reported and fixed.

- Jonathan M Davis