Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?

Hi,

- The done() problem only showed when memory was modified somehow by the user e.g. from a monitor. Reading and scrolling memory should not have shown the same behavior, at least not for that reason (as you found out).

- Timeout: actually there is a variant of the query.get() with a timeout parameter and your suggestion should be considered. Thanks.

- Request flood: I think we suspected that the issue was tied to the traditional memory rendering (i.e. not the service per se) and that a bug was open for that;

See: http://dev.eclipse.org/mhonarc/lists/dsdp-dd-dev/msg01594.html
and: https://bugs.eclipse.org/bugs/show_bug.cgi?id=252130

I realize that there hasn't been much visible activity on that bug so far but I believe that Ted is working on it (and he is the man :-)

Best Regards,
/fc


On Thu, Jan 22, 2009 at 6:16 AM, Mario Pierro <Mario.Pierro@xxxxxxx> wrote:

Hello,

 

Unfortunately the request flood is still there even after applying the patch to DsfMemoryBlock L

 

Now the writing to memory issue is fixed both in GDB and our debugger, thanks.

 

A proposal:

 

Wouldn't it be better to have the query.get() calls in DsfMemoryBlock.writeMemoryBlock() and fetchMemoryBlock() fail after a timeout? Or should the timeout happen in the IMemory service implementation, throwing an ExecutionException if needed?

 

Thanks,

 

Mario

 


From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: den 22 januari 2009 09:17


To: Device Debugging developer discussions
Subject: RE: [dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?

 

Hello,

 

I am glad that this has been fixed!

 

There had been a discussion in this mailing list some time ago about our implementation of the IMemory service being flooded with calls when the mouse wheel was used to scroll the Memory View.

 

http://dev.eclipse.org/mhonarc/lists/dsdp-dd-dev/msg01568.html

 

The missing done() / thread leak when fetching memory blocks could have been the cause for the slowdown we had…

 

I'll try that again with the patched version of DsfMemoryBlock to check if there are any improvements.

 

Thanks!

 

/Mario



Back to the top