[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] EDC and asynchronous operations
|
Yes. That's my understanding, too. And it makes sense. But, again, it
seems useful only when you know up front exactly what set of data points
you need for the transaction.
At 10:37 PM 10/11/2010, Pawel Piech wrote:
I'm also just feeling my way out
on this as I haven't had a chance to implement anything with it
yet. It seems that what ACPM needs (besides a new name) is a good
article which explains what it's good for.
From what I do know about it is that it's a model for using asynchronous
APIs (such as the TCF protocol or DSF services) without writing code with
a lot of callbacks, as we do now. However, the price for avoiding
the callbacks is using these cache objects everywhere, and the price of
using these cache objects is that it forces you to adopt a certain API
for your cache. But as long as all the data you need to get
is available through such cache objects, then you can write all your
logic inside these continuous transaction without the need to break them
up into callback implementations.
I don't know if this is making any sense to you... maybe we need some
simple example to use as a study.
Cheers,
Pawel
On 10/11/2010 03:42 PM, John Cortell wrote:
Hm. So what I can make out so
far is that ACPM is good when you need a discrete set of data points and
that set is completely known up front. With a stack crawl, you don't
really know up front have far down you have to drill, or in which
direction. You need to drill a little before knowing what your next move
is.
Interesting idea...using ACPM for client access. But I'm not sure how
practical that would be. Clients using such access would be unreliable,
right? If the cache is invalidated, the client is screwed unless it has a
plan B to use the asynchronous calls. And coding something to try one way
(simple), then another if needed (harder) isn't really a simplification.
Then again, perhaps I'm misunderstanding your suggestion. Or perhaps
you're thinking of situations where the client is willing to abort the
request altogether if the cache is invalid (even though real-time data
could be obtained)
John
At 04:39 PM 10/11/2010, Pawel Piech wrote:
Hi John,
It would be great if you could verify the logic in these utilities.
I haven't really had time to come back to them since I posted this
bug.
For this case though, I'm not sure if we'll get a lot of milage out of
ACPM inside the DSF services. The bigger benefit would be if we
exposed some form of the ACPM cache objects in the DSF services.
(e.g.)
interface IACPMStack {
...
ICache<IStackFrameDMData>
getStackFameData(IStackFrameDMContext ctx);
...
}
then the clients of such a service could be written to avoid the more
tedious asynchronous style.
For the EDC services, I agree that they just need to be fixed.. and
hopefully it won't expose any timing problems in the larger
implementation.
Cheers,
Pawel
On 10/11/2010 01:47 PM, John Cortell wrote:
OK, well let me help here by
diving into Pawels prototype and seeing if it meets our needs and seeing
how we can apply it in EDC, or see if we can improve those utilities.
I'll also change the implementation of Registers.getRegisterValue() and
look where else this sort of thing is done.
John
At 03:42 PM 10/11/2010,
ken.ryall@xxxxxxxxx wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_C8D8E10229ECDkenryallnokiacom_"
John,
Glad you brought this up, it is an area in EDC that needs some review and
probably some re-work. Everything should work asynchronously if possible
but in some cases, like implementing the stack service, making a series
of synchronous calls is really useful. ACPM looks promising for this, but
I havent had the opportunity to review 310345 yet. I would like to
try this out and clean things up for Indigo.
The implementation of
org.eclipse.cdt.debug.edc.services.Registers.getRegisterValue(RegisterDMC,
DataRequestMonitor<String>),
doesnt make much sense to me either, it should certainly be
redone.
- Ken
From: ext John Cortell
<rat042@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
Date: Mon, 11 Oct 2010 22:01:49 +0200
To: "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
Subject: [cdt-dev] EDC and asynchronous operations
Ken,
Can you speak to the synchronous implementations EDC has for asynchronous
DSF services. E.g., EDC's implementations of, e.g.,
- IStack.getFrames(IDMContext,
DataRequestMonitor<IFrameDMContext[]>)
- IStack.getLocals(IFrameDMContext,
DataRequestMonitor<IVariableDMContext[]>)
synchronously gather the data from the TCF backend, which seems to
defeat the asynchronous nature of DSF. I.e., the DSF executor thread is
tied up during the entire time EDC is pulling together the stack crawl
(or local variables) through a series of low-level TCF calls (reading
registers and memory). The current implementation reduces asycnhronous
calls to synchronous ones at both the DSF boundary and the TCF
one.
Should we not instead be looking at ACPM, taking Pawel's prototype work
as a starting point
https://bugs.eclipse.org/bugs/show_bug.cgi?id=310345
Additionally, I see the watering down of aync calls to sync ones even
where it doesn't seem to simplify things. Eg., in
org.eclipse.cdt.debug.edc.services.Registers.getRegisterValue(RegisterDMC,
DataRequestMonitor<String>),
the call is given a request monitor, but the implementation calls TCF
synchronously and waits an arbitrary 15 seconds for the response to
return.
John
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev