Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Trygve Inda 
>> 
>> I would think that even with a retain it could get weird...
>> 
>> The main thread wants to use the imageRef property so it calls:
>> 
>> myRef = [window.imageRef];
>> [myref retain];
>> 
>> If right between these calls, the worker thread calls setImageRef (on a
>> property with atomic, copy), then the retain call in the main thread might
>> be on something that has already gone away.
>> 
>> I just don't see how I can safely set the property on a worker thread and
>> read it on the main thread without some risk of it being released behind my
>> back.
> 
> As Graham points out, and as we used to discuss often back in the old MRR
> days, atomic getters likely put the value in the autorelease pool, you should
> go see if that’s the case or not.

How can I tell? I can't even do a retainCount without first calling the
getter.





___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Roland King 
> 
> I would think that even with a retain it could get weird...
> 
> The main thread wants to use the imageRef property so it calls:
> 
> myRef = [window.imageRef];
> [myref retain];
> 
> If right between these calls, the worker thread calls setImageRef (on a
> property with atomic, copy), then the retain call in the main thread might
> be on something that has already gone away.
> 
> I just don't see how I can safely set the property on a worker thread and
> read it on the main thread without some risk of it being released behind my
> back.

As Graham points out, and as we used to discuss often back in the old MRR days, 
atomic getters likely put the value in the autorelease pool, you should go see 
if that’s the case or not, if so, it’s protected for as long as that pool isn’t 
drained, and it’s your pool on the main thread, so it won’t be drained between 
those calls. In that case you don’t even need to add the extra retains, however 
for good practice, why not. 

If atomic getters don’t work like that then they are fairly useless. 
___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Trygve Inda 
> 
>> On 27 Jul 2016, at 12:05 PM, Trygve Inda  wrote:
>> 
>> How is it retained by the main thread without an explicit retain call?
>> 
>> I would be no different than a main thread calling:
>> 
>> someVar [[MyObj alloc] init]
>> [someVar doSomething];
>> 
>> If a worker thread were able to call [someVar release] between these two
>> lines, the doSomething call could fail.
> 
> 
> The atomic setter method probably looks something like this:
> 
> - (void) setImageRep:(NSImageRep*) rep
> {
> @synchronized( self )
> {
> [rep retain];
> [_imageRep autorelease];
> _imageRep = rep;
> }
> }
> 
> i.e. the old value is autoreleased. Which thread’s pool gets that autorelease
> is a matter for consideration though. I have no idea if it’s just left to the
> caller’s pool, or if there are steps taken to ensure it ends up in the main
> pool. Even if it’s the caller’s pool, unless you’re draining it on each loop,
> it may only ever get drained when the thread ends, which is safe. But it could
> accumulate a lot of unreleased memory which is another potential problem.
> 
> Threads are tricky ;)

And BTW I am draining the pool on each loop of the worker thread.




___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Trygve Inda 
> 
>> On 27 Jul 2016, at 10:05, Trygve Inda  wrote:
>> 
>>> 
>> 
>> How is it retained by the main thread without an explicit retain call?
> 
> are you not using ARC? If you are then all such references, both variable and
> during method calls are retained automatically. If you’re not, then do what
> ARC does and retain it explicitly and release it explicitly (and start using
> ARC in that case!)

This is non-ARC code. It is a large project and convertig to ARC is a huge
amount of work.

>> 
>> I would be no different than a main thread calling:
>> 
>> someVar [[MyObj alloc] init]
>> [someVar doSomething];
> 
> That isn’t compilable code. Did you mean
> 
> someVar = [ [ MyObj alloc]init ]
> [ someVar doSomething ];

Yes.

> 
> Again if you’re using ARC, none of these issues are issues.
> 
> Why would a worker thread call [ someVar release ] on a variable it didn’t
> retain in the first place? If that’s actually a realistic scenario and you’re
> not using ARC, then call retain on someVar when you assign it in the first
> place and release it only after you’re finished with it, after the call to
> doSomething. Which, by the way, is pretty much what ARC does.

I would think that even with a retain it could get weird...

The main thread wants to use the imageRef property so it calls:

myRef = [window.imageRef];
[myref retain];

If right between these calls, the worker thread calls setImageRef (on a
property with atomic, copy), then the retain call in the main thread might
be on something that has already gone away.

I just don't see how I can safely set the property on a worker thread and
read it on the main thread without some risk of it being released behind my
back.









___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Roland King 

> On 27 Jul 2016, at 10:05, Trygve Inda  wrote:
> 
>> 
> 
> How is it retained by the main thread without an explicit retain call?

are you not using ARC? If you are then all such references, both variable and 
during method calls are retained automatically. If you’re not, then do what ARC 
does and retain it explicitly and release it explicitly (and start using ARC in 
that case!)

> 
> I would be no different than a main thread calling:
> 
> someVar [[MyObj alloc] init]
> [someVar doSomething];

That isn’t compilable code. Did you mean

someVar = [ [ MyObj alloc]init ]
[ someVar doSomething ];


> 
> If a worker thread were able to call [someVar release] between these two
> lines, the doSomething call could fail.
> 

Again if you’re using ARC, none of these issues are issues. 

Why would a worker thread call [ someVar release ] on a variable it didn’t 
retain in the first place? If that’s actually a realistic scenario and you’re 
not using ARC, then call retain on someVar when you assign it in the first 
place and release it only after you’re finished with it, after the call to 
doSomething. Which, by the way, is pretty much what ARC does. 



> 
> 


___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Graham Cox 

> On 27 Jul 2016, at 12:18 PM, Graham Cox  wrote:
> 
> The atomic setter method probably looks something like this:


A further thought. If the getter method is also protected, like:

- (NSImageRep*) imageRep
{
@synchronized( self )
{
return [[_imageRep retain] autorelease];
}
}


Then you’ll also be safe.

I have no idea if this is what synthesized atomic getters look like though.

—Graham



___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Graham Cox 

> On 27 Jul 2016, at 12:05 PM, Trygve Inda  wrote:
> 
> How is it retained by the main thread without an explicit retain call?
> 
> I would be no different than a main thread calling:
> 
> someVar [[MyObj alloc] init]
> [someVar doSomething];
> 
> If a worker thread were able to call [someVar release] between these two
> lines, the doSomething call could fail.


The atomic setter method probably looks something like this:

- (void)setImageRep:(NSImageRep*) rep
{
@synchronized( self )
{
[rep retain];
[_imageRep autorelease];
_imageRep = rep;
}
}

i.e. the old value is autoreleased. Which thread’s pool gets that autorelease 
is a matter for consideration though. I have no idea if it’s just left to the 
caller’s pool, or if there are steps taken to ensure it ends up in the main 
pool. Even if it’s the caller’s pool, unless you’re draining it on each loop, 
it may only ever get drained when the thread ends, which is safe. But it could 
accumulate a lot of unreleased memory which is another potential problem.

Threads are tricky ;)

—Graham



___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Trygve Inda 
> 
>> On 27 Jul 2016, at 09:33, Trygve Inda  wrote:
>> 
>> 
>> 
>> If the worker thread calls window.imageRep = myResult; it is possible that
>> the main thread is in the middle of a call like:
>> 
>> [[window.imageRep]
>> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]
>> 
>> So when the setter (called from the worker thread) replaces the old imageRep
>> with a new one, the old one's retain count goes to zero and it will
>> disappear.
>> 
>> I know atomic makes the call safe as far as a vaild value is concerned, but
>> the main thread could call window.imageRep and get a valid value (because it
>> is atomic), but before it is able to use this value, the worker thread calls
>> the setter which causes the imageRep obtained by the main thread to be
>> released.
> 
> No it couldn’t - because when the main thread calls window.imageRep it gets a
> reference which, whether it assigns it to a variable or just uses it in in a
> chained call (like you have above with drawInRect:.) is retained by the main
> thread during the life of that variable or during the call. So it doesn’t
> matter if the worker thread replaces it after the call to window.imageRep, the
> main thread’s reference remains valid and usable and is only released when
> it’s finished with it and only then gets deallocated (if nothing else is
> referencing it)
> 

How is it retained by the main thread without an explicit retain call?

I would be no different than a main thread calling:

someVar [[MyObj alloc] init]
[someVar doSomething];

If a worker thread were able to call [someVar release] between these two
lines, the doSomething call could fail.




___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Roland King 

> On 27 Jul 2016, at 09:33, Trygve Inda  wrote:
> 
> 
> 
> If the worker thread calls window.imageRep = myResult; it is possible that
> the main thread is in the middle of a call like:
> 
> [[window.imageRep] 
> drawInRect:fromRect:operation:fraction:respectFlipped:hints:]
> 
> So when the setter (called from the worker thread) replaces the old imageRep
> with a new one, the old one's retain count goes to zero and it will
> disappear.
> 
> I know atomic makes the call safe as far as a vaild value is concerned, but
> the main thread could call window.imageRep and get a valid value (because it
> is atomic), but before it is able to use this value, the worker thread calls
> the setter which causes the imageRep obtained by the main thread to be
> released.

No it couldn’t - because when the main thread calls window.imageRep it gets a 
reference which, whether it assigns it to a variable or just uses it in in a 
chained call (like you have above with drawInRect:.) is retained by the main 
thread during the life of that variable or during the call. So it doesn’t 
matter if the worker thread replaces it after the call to window.imageRep, the 
main thread’s reference remains valid and usable and is only released when it’s 
finished with it and only then gets deallocated (if nothing else is referencing 
it)


___

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

Re: NSImage from bitmap - then delete bitmap

2016-07-26 Thread Trygve Inda 

> e.g.
> 
> worker thread:
> 
> while( self.running )
> {
> // do work
> 
> window.imageRep = myResult;  // window.imageRep is (atomic, copy)
> 
> [performOnMainThread: window.setNeedsDisplay];  // this is obviously
> pseudocode!
> }
> 
> 
> main thread, when it needs to terminate worker thread:
> 
> workerThread.running = NO;
> 
> 
> both workerThread.running and window.imageRep are atomic properties.

I am not sure this is safe.

window.imageRep is (atomic, copy)

If the worker thread calls window.imageRep = myResult; it is possible that
the main thread is in the middle of a call like:

[[window.imageRep] 
drawInRect:fromRect:operation:fraction:respectFlipped:hints:]

So when the setter (called from the worker thread) replaces the old imageRep
with a new one, the old one's retain count goes to zero and it will
disappear.

I know atomic makes the call safe as far as a vaild value is concerned, but
the main thread could call window.imageRep and get a valid value (because it
is atomic), but before it is able to use this value, the worker thread calls
the setter which causes the imageRep obtained by the main thread to be
released.

I think you'd only want to call the setter from the main thread.



___

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

Re: Codesign assumes folder structure, fails.

2016-07-26 Thread Greg Parker 

> On Jul 25, 2016, at 6:15 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> I’m getting an error from codesign when it tries to sign a third-party 
> embedded framework.
> 
> The error is:
> 
> /Users/grahamcox/Library/Developer/Xcode/DerivedData/Drawkit-hlbdxcwqkoiqzlesbkfsrobctzke/Build/Products/Debug/Ortelius
>  2.app/Contents/Frameworks/GEOS.framework/Versions/A: No such file or 
> directory
> Command /usr/bin/codesign failed with exit code 1
> 
> The problem is that GEOS.framework/Versions/A doesn’t exist. That’s true - 
> the alias ‘Current’ points to a folder called ‘3’ within Versions which 
> contains the executable. ‘A’ doesn’t exist. (i.e. the path is 
> GEOS.framework/Versions/3, and this is where GEOS.framework/Versions/Current 
> points to)
> 
> Isn’t this a serious bad assumtion on the part of codesign? Surely the bundle 
> folder structure for executables has always allowed the ‘current’ version to 
> be changed, and ‘A’ is merely the conventional name for version 1, followed 
> by ‘B’, etc? In this case it seems to be using ‘3’ in a sequence which may 
> once have held ‘1’, ‘2’…
> 
> This is a 3rd party framework, I have not built it myself, and I’d rather not 
> have to if I can help it. Renaming the folders is easy enough, but 
> nevertheless I would expect codesign to understand the long-standing 
> versioning schema within a bundle.
> 
> Bug or reasonable assumption?

My understanding is that this is a limitation of the Xcode build system. 
codesign doesn't care about the framework's structure, but Xcode does and it is 
telling codesign to look at the wrong path. You should mention rdar://17814234 
when you file your bug report.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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