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.
