NSMutableData currently ignores (and always has, to my knowledge) the no-copy 
"hint" and always copies the bytes into an internal buffer in case something 
tries to change the length of the NSMutableData.

It would not be too difficult to make a subclass of NSMutableData that doesn't 
copy and throws an exception when something tries to change the length. That 
would violate the Liskov substitution principle though, so at the very least, 
you want to prevent any code that doesn't understand the fixed-length 
restriction from getting ahold of one of these objects.

[kevin perry];

On Dec 13, 2012, at 2:28 PM, Robert Monaghan <b...@gluetools.com> wrote:

> Hi Everyone,
> 
> I have just run head long into an issue with NSMutableData and existing 
> buffers.
> I have the following code:
> 
> 
>                       UInt8 *sourcebytes = [clImgEngine srcBuffer];
>                       [self setData:[NSMutableData 
> dataWithBytesNoCopy:sourcebytes length:[clImgEngine inRangeByteCount] 
> freeWhenDone:NO]];
>                       UInt8 *resultBytes = [[self data] mutableBytes];
> 
> The source is a pinned memory buffer from OpenCL. What I want to do, is to 
> pass this buffer inside a NSMutableData wrapper and have another object for 
> some work.
> Seems simple enough, except that NSMutableData changes the memory buffer in 
> the background.
> 
> "sourcebytes" starts with an address such as: 0x000000012361b000
> and "resultBytes" returns 0x0000000136fe2000
> 
> Naturally, my work object doesn't see any data from "sourcebytes", as 
> NSMutableData has moved the buffer.
> I thought that freeWhenDone:NO prevented ownership of the buffer..
> 
> Can anyone suggest a way to prevent this from happening? I need the buffer to 
> stay "pinned".
> 
> Thanks in advance!
> 
> bob.
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
> 
> This email sent to kpe...@apple.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to