O.K. so picking up this idea of an external function that would return the multithreaded trace
information that then could be used for insertion in one own's trace enhancement in the context of
adding multithreaded trace.
The question would be what should be the name of such a function, which s
Time passes too quickly.
@Rick: do you have any intentions to implement the ideas you have communicated?
---rony
On 25.03.2023 16:58, Rick McGuire wrote:
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater wrote:
Let me see if I've got this. If there was a class, perhaps a subclass
Is there any news on this?
As long as these thoughts of enhancements are missing in form of real code one cannot use them to
debug mulit-threaded programs with the necessary context information. Therefore the question when
any such changes can be expected?
Or would it be better for the moment
So it turns out that under Windows, it is easy to obtain the thread ID
of the current running code. My framework now does that so it might be
of use, as is, to anyone needing to know which thread executed the line
being traced. Gil
On 4/1/2023 5:01 PM, Gilbert Barmwater wrote:
Well, FWIW, I
Well, FWIW, I thought so too. Just for fun I have implemented a working
framework of what I described later in this thread. Of course, even
though it can modify the trace output, it does not actually put the
"real" values in as that would require either the modifications to the
.stackframe cl
That sounds very interesting!
—-rony
Rony G. Flatscher (mobil/e)
> Am 25.03.2023 um 07:35 schrieb Rick McGuire :
>
>
> I had one of those AHA moments this morning. The whole question about
> multithreaded tracing can be quite cleanly resolved by removing the question
> from the TRACE comman
On 3/25/2023 11:58 AM, Rick McGuire wrote:
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater
wrote:
Let me see if I've got this. If there was a class, perhaps a
subclass
of outputStream, that implemented a SAY method which would
"collect" the
additional multi-threading
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater
wrote:
> Let me see if I've got this. If there was a class, perhaps a subclass
> of outputStream, that implemented a SAY method which would "collect" the
> additional multi-threading information and add it to the argument that
> it receives, the
Let me see if I've got this. If there was a class, perhaps a subclass
of outputStream, that implemented a SAY method which would "collect" the
additional multi-threading information and add it to the argument that
it receives, then one would only need to create an instance of that
class associ
