Hi,
This rings a bell. A while ago I started to do something like this. My idea was to better support cameras/drivers that want to manage the image memory (and avoid superfluous copies). A callback can be registered and you can decide whether to re-use or free the memory. It does not address the issue of some plugins holding on (forever?) to their latest received image - but I think that's a bit of a naughty behaviour...
The commits are rather old and would need to be rebased on top of the latest ADCore master branch...
https://github.com/ulrikpedersen/ADCore/commit/3e2910680b5d65ffb881304cff49cf568f13e80c and https://github.com/ulrikpedersen/ADCore/commit/db7199a110d203c7712b66ac925145ffb54b5966
Cheers,
Ulrik
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Rivers
Sent: 29 July 2016 17:39
To: 'Michael Davidsaver'; [email protected]; 'Phil Atkin'
Subject: RE: NDArrayPool::alloc failing
Hi Michael,
This is an excellent suggestion.
Phil, this should solve your problem. Your driver will get a callback when the array has been released. You can then do what you want with the buffer pointer, being confident that no plugin is using it. If you want to implement it in NDArrayPool and NDArray you can then issue a pull request on Github.
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Davidsaver
Sent: Friday, July 29, 2016 9:37 AM
To: [email protected]
Subject: Re: NDArrayPool::alloc failing
On 07/29/2016 09:29 AM, Mark Rivers wrote:
> We could add an NDArray::getReferenceCount method. If you have the array reserved and getReferenceCount=1 then you can be sure all the plugins have released it.
A good interface to handle this sort of situation would be for
NDArrayPool::alloc() to accept a callback function pointer to "cleanup"
the user provided buffer when the NDArray ref. count falls to zero.
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- Replies:
- Re: NDArrayPool::alloc failing Phil Atkin
- References:
- NDArrayPool::alloc failing Phil Atkin
- RE: NDArrayPool::alloc failing Mark Rivers
- Re: NDArrayPool::alloc failing Phil Atkin
- RE: NDArrayPool::alloc failing Mark Rivers
- Re: NDArrayPool::alloc failing Michael Davidsaver
- RE: NDArrayPool::alloc failing Mark Rivers
- Navigate by Date:
- Prev:
Re: shell command in medm Southern, Tim
- Next:
PCASpy 0.6.2 Wang Xiaoqiang (PSI)
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: NDArrayPool::alloc failing Mark Rivers
- Next:
Re: NDArrayPool::alloc failing Phil Atkin
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|