std.experimental.logger formal review round 3

[Kevin Lamonte via Digitalmars-d]

On Wednesday, 1 October 2014 at 13:37:43 UTC, Dicebot wrote:
> On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte 
> wrote:
>> 2. We have Tid in the API.  What about Fiber and Thread?  If 
>> we can only pick one, I would vote for Thread rather than Tid, 
>> as Tid's currently have no way to be uniquely identified in a 
>> logging message.  Reference: 
>> https://issues.dlang.org/show_bug.cgi?id=6989
>
> In my opinion only solution that scales is to provide same ID 
> as one used by std.concurrency - it can be thread, fiber, 
> process or pretty much anything. There are many possible 
> threading abstractions and all can't be easily supported, makes 
> sense to stick to one considered standard.

Long-term this sounds very reasonable.  But the problem at the 
moment is that std.concurrency provides nothing that can be used 
to distinguish threads in a log file.  Tid cannot be converted to 
a unique string or vice versa, nor can one Tid.join() to ensure 
that a child Thread has completed before closing the log file(s) 
and exiting main().  For boring end-user applications Threads are 
today's most common denominator.

Would PR 
https://github.com/D-Programming-Language/phobos/pull/1910 
provide a way given a Tid to determine: a) What underlying 
concurrency model it is using (Thread, Fiber, process, future)? 
b) Uniquely identify that structure (Thread ID string, Fiber 
address string, process ID, something else)?  c) Be capable of 
using that identifying immutable (because it needs to be 
send()able to another Tid writing to network/file/etc) 
string-representable thing to find the original Tid again?  A+B 
is necessary for using std.logger to debug concurrent 
applications, C is a very nice-to-have that comes up periodically.