Forgot to mention, BTW, there's a mini-app in utracer/*.[ch] that shows
the utracer API in use in a fake GTK-based debugger.
Phil Muldoon wrote:
Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view", non-ordered repl
Phil Muldoon wrote:
Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view", non-ordered replies to asynchronous
requests present an ordering conundrum in the client - especially as
it scales to many many inferiors.
Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view", non-ordered replies to asynchronous
requests present an ordering conundrum in the client - especially as
it scales to many many inferiors.
I tend to think of t
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client implementation
"point of view", non-ordered replies to asynchronous requests present
an ordering conundrum in the client - especially as it scales to many
many inferiors.
I tend to think of the asynch stuff not a
Phil Muldoon wrote:
Chris Moller wrote:
No guarantees, of course--the next-generation stuff may do things
differently--but even as I type this, I'm hacking together a
boilerplate framework that does exactly as described above.
Missed this in the last question, so apologies for the multiple
Chris Moller wrote:
No guarantees, of course--the next-generation stuff may do things
differently--but even as I type this, I'm hacking together a
boilerplate framework that does exactly as described above.
Missed this in the last question, so apologies for the multiple emails.
When can I get
Chris Moller wrote:
Phil Muldoon wrote:
Roland McGrath wrote:
I think of the interface as asynchronous at base. There may at some
point be some synchronous calls to optimize the round trips. But we
know that by its nature an interface for handling many threads at once
has to be asynchronous
