Issue 6989 - Create a better string representation of Tid's for easier thread identification and debugging.

[ghost]

http://d.puremagic.com/issues/show_bug.cgi?id=6989

I'm thinking of actually implementing an opEquals method as well, which simply would compare the threadID fields.

Edit: Nevermind about opEquals, it's unnecessary because this is automatic thanks to the .tupleof == .tupleof rewrite on == aggregate expressions.

Maybe there's an even better way to implement toString, perhaps by inspecting mbox or some other field. But I figured this would be the simplest way to do it without depending on OS-specific thread identifiers.

[ghost]

Btw, I've used the sink version of toString since I want to avoid memory allocation, but then again I'm not sure if we have a way to avoid the allocations when converting a size_t to a string. Can format itself take a sink? If so I could just redirect it, e.g. (pseudocode):

formatSink(sink, "%s", threadID);

Or whatever the function name is if it exists.

[JakobOvrum]

Yes, std.format.formattedWrite is supposed to work with a sink, but I don't think it will work at present. I believe @monarchdodra has been spending time on this problem recently.

I guess a possible work-around would be to use sformat with a buffer big enough for any possible value of threadID; that shouldn't be hard. I hear that sformat can still allocate heap memory even on success though, but surely it's an improvement over straight-up format, especially with the future in mind.

edit:

BTW, as long as a formatting function is used, it's probably best to put the Tid(...) enclosing right there in the format string too, to reduce the calls to the sink.

[monarchdodra]

formatValue (and formattedWrite), should work with a sink. The only limitation is that none of the passed args arguments are strings, or wide characters:
http://d.puremagic.com/issues/show_bug.cgi?id=10571

For wide chars, it is an obvious and stright up bug.

For strings, it's more complex. I'd need to double check, but there is a code branch for raw write ("%r") of strings that makes formattedWrite iterate over the string as range of dchars, and you can't palce a dchar in a string sink. Since I have no idea what "raw" is actually supposed to do, I don't even know if its correct behavior or not to do it that way. My fix works around that problem, but I think a deeper review of what formatValue actually does would be needed.

If you do need to put a string into the sink, then chances are you don't actually need to format it, so a straight up "put" will workaround that problem.

Anywhoo, back to the subject. TL;DR; In your case,

formattedWrite(sink, "Tid(%s)", threadID);

Should 100% work no problem, and not allocate either (as far as the write is concerned of course, the sink itself can do anything it wants).

[JakobOvrum]

It should not allocate, but apparently it still does, and that's not talking about the obvious case of allocating exceptions in case of failure. Anyway, not really relevant to this PR...

[monarchdodra]

It should not allocate, but apparently it still does

Really? How do you know? And where does it do so?

[monarchdodra]

Since I have no idea what "raw" is actually supposed to do

I investigated, and I came to the conclusion that it is completly wrong. I'll have to fix this directly.

[monarchdodra]

I investigated, and I came to the conclusion that it is completly wrong. I'll have to fix this directly.

I fixed it! :)

It was just silly meta mistakes.

[yebblies]

Yeah, ideally this would be formattedWrite(sink, "Tid(%s)", threadID); but using sink(threadID) is much better than format.

[ghost]

Closing until I figure out the appropriate fix.

[ghost]

Also worth noting that storing the ID In the struct would increase the memory size of Tid, which may not be what we want.

Anyway, before I go forward again I need to figure out how to get the thread identifier of the thread that owns the Tid, probably through the message box somehow.

[ghost]

Naive question, but why not just store Thread.getThis.toHash in struct Tid? Will Thread.toHash() change during the lifetime of Tid?

[ghost]

@klamonte: You could give this a try if you want to make a pull request. :)

[ghost]

Naive question was naive. But let's give it a shot anyway. ;-)

#2482