Threadsafe copy of objective c object
This feels like it should be a very basic question, but it's not one I've managed to find an answer to - can somebody here advise? I have an objective c object which contains a number of properties that serve as parameters for an algorithm. They are bound to UI elements. I would like to take a snapshot copy of the object that will be used for one whole run of the algorithm (rather than risk parameters changing halfway through the run). i.e. I just want to do [myObject copy]. The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. Is there any way, then, that I can take a copy in a threadsafe manner? If necessary I can do the copy on the main thread, but I would prefer not to have to do that for timing reasons. Any suggestions? Cheers Jonny. ___ 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: Threadsafe copy of objective c object
On 03/09/2013, at 12:52 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a lock
which should make the copy thread-safe.
--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: Threadsafe copy of objective c object
Ah, that's a good point about implementing -copy myself. However, how would
@synchronized(self){…..} help there? Surely all that would do is prevent
multiple threads from calling 'copy' simultaneously - which as far as I am
aware isn't something I should be worried about. My understanding is that it
would have no impact on whether for example the copied object contains correct
values.
If it's relevant, I should add that the object's properties are all simple
types (double, int, bool etc).
It doesn't help that I'm not really sure what window conditions I am guarding
against in my desire for thread safety, which makes my question a little vague.
I guess that what I would like is the following:
- [myObject copy] will not crash/raise exceptions/etc when called from a
thread other than the main thread
- [myObject copy] returns a copy in which all parameters are 'valid'
(i.e. an individual parameter is either the 'old' or the 'new' value in the
case where the object is being changed at the time of the copy)
- True thread safety would require a copy that represents an
instantaneous snapshot of the state of the entire object, i.e. copy not taken
while object is being updated. Actually, I suspect this last condition is not a
problem for my specific case, but best to be on the safe side, for several
different reasons.
On 3 Sep 2013, at 12:04, Graham Cox wrote:
On 03/09/2013, at 12:52 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
--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: Threadsafe copy of objective c object
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
No, it wouldn't. It would only ensure that two calls to copy are executed
sequentially. You would need to add @synchronized(self) {…} to all other
methods that modify the object too to ensure that the object isn't changed
during a copy.
Lasse
Sent with Unibox
___
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: Threadsafe copy of objective c object
Hi,
Basically you are trying to protect the values of an object while you are
copying.
If this is the case, then wherever you access these properties you will be need
to use a lock based on the object you are copying.
In order to do this, you need to lock the whole object whenever you are
accessing the values, one way of doing this is to do something like this:
SafeObj*myCurrentObject;//Assume set to object
you wish to copy.
SafeObj*myNewObject;
//**
//** Read Values
//**
myNewObject = [[SafeObj alloc] initWithObject: myCurrentObject];
Then in initWithObject, do this:
- (id) initWithObject:(SafeObj*) theObject;
{
self = [self init];
if (self == nil)
return nil;
@sychronized(theObject)
{
self.pVal1 =theObject.pVal1;
self.pVal2 =[theObject.pVal2 copy];
self.pVal3 =[theObject.pVal2 mutableCopy];
}
return self;
}
Of course, in the rest of the code that accesses pValX, you'd need to add
@synchronized around getting and setting them. The properties obviously need to
be protected as a set, so to read them, create a new local object using
initWithObject to copy the values.
To write to a set, you need to add another method:
-(void) setValuesFromObject::(SafeObj*) theObject;
{
@sychronized(self)
{
self.pVal1 =theObject.pVal1;
self.pVal2 =[theObject.pVal2 copy];
self.pVal3 =[theObject.pVal2 mutableCopy];
}
}
So, to increment pVal1, you'd do this:
SafeObj*myCurrentObject;//Assume set to object
you wish to copy.
SafeObj*myNewObject;
//**
//** Read Values
//**
myNewObject = [[SafeObj alloc] initWithObject: myCurrentObject];
myNewObject.pVal1++;
[self setValuesFromObject: myNewObject];
Hope this helps
Dave
On 3 Sep 2013, at 11:52, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote:
This feels like it should be a very basic question, but it's not one I've
managed to find an answer to - can somebody here advise?
I have an objective c object which contains a number of properties that serve
as parameters for an algorithm. They are bound to UI elements. I would like
to take a snapshot copy of the object that will be used for one whole run of
the algorithm (rather than risk parameters changing halfway through the run).
i.e. I just want to do [myObject copy].
The complication is in ensuring this is threadsafe: ideally I would like to
make the copy on a thread other than the main thread. My understanding is
that properties themselves, even when designated atomic, are in some way not
fully threadsafe, although I haven't found a clear explanation of exactly
what makes them unsafe. I don't know if the 'copy' method is threadsafe or
not, I am inclined to suspect not.
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
Cheers
Jonny.
___
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/dave%40looktowindward.com
This email sent to d...@looktowindward.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
Re: Threadsafe copy of objective c object
Is it possible to reverse the issue? Keep the original object (living on the
main thread) untouched, make a copy for algorithm processing as an async task,
then, when done, update the original object from the copy that may have been
changed during async processing? Or will that cause the exact same problem in
the final step?
Verstuurd vanaf mijn iPhone
Op 3 sep. 2013 om 13:16 heeft Lasse Jansen la...@lasselog.com het volgende
geschreven:
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
No, it wouldn't. It would only ensure that two calls to copy are executed
sequentially. You would need to add @synchronized(self) {…} to all other
methods that modify the object too to ensure that the object isn't changed
during a copy.
Lasse
Sent with Unibox
___
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/diederik%40tenhorses.com
This email sent to diede...@tenhorses.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
Re: Threadsafe copy of objective c object
On 03/09/2013, at 1:23 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Ah, that's a good point about implementing -copy myself. However, how would
@synchronized(self){…..} help there? Surely all that would do is prevent
multiple threads from calling 'copy' simultaneously - which as far as I am
aware isn't something I should be worried about. My understanding is that it
would have no impact on whether for example the copied object contains
correct values.
It wasn't really clear from your post where it needs to be thread safe. It
sounded as though you wanted to call copy on the original object from
multiple threads. As Lasse pointed out, that's not enough if the copied values
can be changed.
If it's relevant, I should add that the object's properties are all simple
types (double, int, bool etc).
If they are declared as atomic, I believe you can trust that simple types are
thread safe. It's when they are objects that things can still mutate mid-way
through a setter.
It doesn't help that I'm not really sure what window conditions I am guarding
against in my desire for thread safety, which makes my question a little
vague.
Well, indeed.
If you are making a copy of the object for the purpose of passing it as a set
of parameters to some other code, then presumably that object, once copied, is
self-contained and is used on a single thread from then on. That was the
scenario I sort of assumed from your original post. If that's not the case then
you need to make the problem clearer, i.e. is the algorithm multi-threaded in
itself?
--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: Threadsafe copy of objective c object
On 9/3/13 1:23 PM, Jonathan Taylor wrote: - True thread safety would require a copy that represents an instantaneous snapshot of the state of the entire object, i.e. copy not taken while object is being updated. Actually, I suspect this last condition is not a problem for my specific case, but best to be on the safe side, for several different reasons. That means you have to make the copy and write accesses to the individual properties mutually exclusive. Depending on the number of properties in your object, it might be easier to completely exchange the object whenever you want to mutate one if its properties, basically treating the whole object immutable. Copying is trivial then. Of course it depends on how many times a second you need to change properties. Regards Markus -- __ Markus Spoettl ___ 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: Threadsafe copy of objective c object
Opps! Typeo, should read: [myCurrentObject setValuesFromObject: myNewObject]; Dave On 3 Sep 2013, at 11:52, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: This feels like it should be a very basic question, but it's not one I've managed to find an answer to - can somebody here advise? I have an objective c object which contains a number of properties that serve as parameters for an algorithm. They are bound to UI elements. I would like to take a snapshot copy of the object that will be used for one whole run of the algorithm (rather than risk parameters changing halfway through the run). i.e. I just want to do [myObject copy]. The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. Is there any way, then, that I can take a copy in a threadsafe manner? If necessary I can do the copy on the main thread, but I would prefer not to have to do that for timing reasons. Any suggestions? Cheers Jonny. ___ 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/dave%40looktowindward.com This email sent to d...@looktowindward.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/dave%40looktowindward.com This email sent to d...@looktowindward.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
Re: Threadsafe copy of objective c object
Is it possible to reverse the issue? Keep the original object (living on the
main thread) untouched, make a copy for algorithm processing as an async
task, then, when done, update the original object from the copy that may have
been changed during async processing? Or will that cause the exact same
problem in the final step?
Things are simpler than that I think - the object containing the parameters
won't be changed by running the algorithm. The copy that I want to take will be
treated as read-only.
To recap/expand:
The primary instance of the object (call it MyParameters) is bound to UI
elements. Changes to the UI will change the values of its properties
(int/bool/double). These changes will take place on the main thread.
I would like to be able to take a copy of MyParameters from a thread that is
not the main thread, and have that copy be a non-corrupted snapshot of the
primary instance of MyParameters. The copy will not be altered; no changes need
to be propagated back to the primary instance. Indeed, the motivation behind my
question is the *requirement* that this copy does not change in any way
(despite the primary instance possibly changing).
I am not sure how to do this in a fully correct manner. One might naively
expect that designating properties as atomic could be sufficient. However I
have read that even atomic properties are not threadsafe - although I was not
able to establish the reason for this statement. Perhaps that statement only
applies to more complex objects, in which case it may be I am worrying over
nothing.
Op 3 sep. 2013 om 13:16 heeft Lasse Jansen la...@lasselog.com het volgende
geschreven:
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
No, it wouldn't. It would only ensure that two calls to copy are executed
sequentially. You would need to add @synchronized(self) {…} to all other
methods that modify the object too to ensure that the object isn't changed
during a copy.
Lasse
Sent with Unibox
___
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/diederik%40tenhorses.com
This email sent to diede...@tenhorses.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
Re: Threadsafe copy of objective c object
On 3 Sep 2013, at 13:39, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote:
Is it possible to reverse the issue? Keep the original object (living on the
main thread) untouched, make a copy for algorithm processing as an async
task, then, when done, update the original object from the copy that may
have been changed during async processing? Or will that cause the exact same
problem in the final step?
Things are simpler than that I think - the object containing the parameters
won't be changed by running the algorithm. The copy that I want to take will
be treated as read-only.
To recap/expand:
The primary instance of the object (call it MyParameters) is bound to UI
elements. Changes to the UI will change the values of its properties
(int/bool/double). These changes will take place on the main thread.
I would like to be able to take a copy of MyParameters from a thread that is
not the main thread, and have that copy be a non-corrupted snapshot of the
primary instance of MyParameters. The copy will not be altered; no changes
need to be propagated back to the primary instance. Indeed, the motivation
behind my question is the *requirement* that this copy does not change in any
way (despite the primary instance possibly changing).
I am not sure how to do this in a fully correct manner. One might naively
expect that designating properties as atomic could be sufficient. However I
have read that even atomic properties are not threadsafe - although I was
not able to establish the reason for this statement. Perhaps that statement
only applies to more complex objects, in which case it may be I am worrying
over nothing.
Do the values have to be taken as a set? e.g. If you had pVal1, pVal2, pVal3,
and while copying pVal2 gets changed. You can lock individual properties with
atomic, BUT if they are to be treated as a set, then one thread could be
writing to pVal2 while another thread is reading from pVal1.
If this is the case, then you need to lock the whole copy process as per my
last post
Cheers
Dave
Op 3 sep. 2013 om 13:16 heeft Lasse Jansen la...@lasselog.com het volgende
geschreven:
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
No, it wouldn't. It would only ensure that two calls to copy are executed
sequentially. You would need to add @synchronized(self) {…} to all other
methods that modify the object too to ensure that the object isn't changed
during a copy.
Lasse
Sent with Unibox
___
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/diederik%40tenhorses.com
This email sent to diede...@tenhorses.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/dave%40looktowindward.com
This email sent to d...@looktowindward.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
Re: Threadsafe copy of objective c object
On Tue, Sep 3, 2013 at 2:39 PM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
The primary instance of the object (call it MyParameters) is bound to UI
elements. Changes to the UI will change the values of its properties
(int/bool/double). These changes will take place on the main thread.
1. Create MyParameters instance on some object on the main thread and call
it mainParameters for example.
2. All values are UI related, so, fill them on the main thread. But lock
your mainParameters object before. So, on the main thread do this ...
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
myObjectHoldingMyParameters.mainParameters.X = X;
...
}
3. When you do want a copy on any other thread, do this ...
MyParamaters *paramsCopy;
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
paramsCopy = [myObjectHoldingMyParameters.mainParameters copy];
}
... and implement deep copy without locking. It's done via @synchronized.
___
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: Threadsafe copy of objective c object
All sounds nice, except for the fact that the parameters are being changed
behind the scenes via the binding system. So I think I may have to implement
locking on every (explicitly implemented) get/set method. That was what I had
been rather hoping to avoid, but it sounds from what people are saying as if
that's what I may have to do...
On 3 Sep 2013, at 13:54, Robert Vojta wrote:
On Tue, Sep 3, 2013 at 2:39 PM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
The primary instance of the object (call it MyParameters) is bound to UI
elements. Changes to the UI will change the values of its properties
(int/bool/double). These changes will take place on the main thread.
1. Create MyParameters instance on some object on the main thread and call it
mainParameters for example.
2. All values are UI related, so, fill them on the main thread. But lock your
mainParameters object before. So, on the main thread do this ...
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
myObjectHoldingMyParameters.mainParameters.X = X;
...
}
3. When you do want a copy on any other thread, do this ...
MyParamaters *paramsCopy;
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
paramsCopy = [myObjectHoldingMyParameters.mainParameters copy];
}
... and implement deep copy without locking. It's done via @synchronized.
___
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: Threadsafe copy of objective c object
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread
only.
___
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: Threadsafe copy of objective c object
Ah. In my original email I didn't explain *why* it is that ideally I would
like to make the copy on a thread other than the main thread. The algorithm is
doing real-time video processing, and I very much want to avoid holding up
anything in that code path by synchronizing with the main queue. Past
experience has shown that that does lead to glitches I am keen to avoid. So,
while I'm a big fan of such constructions, I'm deliberately trying to avoid
that here.
Serializing access to MyParameters will work, it's just a shame that there
isn't such a tidy way of achieving that...
On 3 Sep 2013, at 14:18, Robert Vojta wrote:
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread only.
___
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: Threadsafe copy of objective c object
On Sep 3, 2013, at 5:39 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
I would like to be able to take a copy of MyParameters from a thread that is
not the main thread
Why?
Sure, you have a thread doing real-time video processing, but how expensive can
it be to make a copy and send it over? Audio Units basically do this and they
are just as real-time.
I think you may be over-optimizing or mis-optimizing given this requirement.
The typical pattern for things like this is that you have an initial set of
parameters, and then as they change you set updates that take effect as soon as
the real-time pipeline can get to them.
I am not sure how to do this in a fully correct manner. One might naively
expect that designating properties as atomic could be sufficient. However I
have read that even atomic properties are not threadsafe - although I was
not able to establish the reason for this statement. Perhaps that statement
only applies to more complex objects, in which case it may be I am worrying
over nothing.
Atomic properties don’t guarantee thread-safety (of an object as a whole) but
are threadsafe individually. The difference is this: Imagine you have an object
with firstName and lastName writable properties, and a fullName derived
property (appends lastName to firstName). Making the properties atomic ensures
that you can safely set firstName and lastName from any thread, but does not
ensure that fullName will always represent the result of a single thread’s work
(assuming each thread sets both properties).
Op 3 sep. 2013 om 13:16 heeft Lasse Jansen la...@lasselog.com het volgende
geschreven:
Since the implementation of -copy is up to you, you could just put
@synchronized(self){…..} around the code in that method. That implements a
lock which should make the copy thread-safe.
No, it wouldn't. It would only ensure that two calls to copy are executed
sequentially. You would need to add @synchronized(self) {…} to all other
methods that modify the object too to ensure that the object isn't changed
during a copy.
Lasse
Sent with Unibox
___
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/diederik%40tenhorses.com
This email sent to diede...@tenhorses.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/david.duncan%40apple.com
This email sent to david.dun...@apple.com
--
David Duncan
___
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: Threadsafe copy of objective c object
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Hope this helps!
(Note: all code was typed in the e-mail, so may not compile.)
Jeff Kelley
On Tue, Sep 3, 2013 at 9:34 AM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
Ah. In my original email I didn't explain *why* it is that ideally I
would like to make the copy on a thread other than the main thread. The
algorithm is doing real-time video processing, and I very much want to
avoid holding up anything in that code path by synchronizing with the main
queue. Past experience has shown that that does lead to glitches I am keen
to avoid. So, while I'm a big fan of such constructions, I'm deliberately
trying to avoid that here.
Serializing access to MyParameters will work, it's just a shame that there
isn't such a tidy way of achieving that...
On 3 Sep 2013, at 14:18, Robert Vojta wrote:
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread
only.
___
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/slaunchaman%40gmail.com
This email sent to slauncha...@gmail.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
Re: Core Data Initialization
On 2 Sep 2013, at 9:33 AM, Jerry Krinock je...@ieee.org wrote wise things about handling mismatches between stores and MOMs, and the practice of copying a generic store into Documents/ if no store is there. On 2013 Sep 02, at 04:01, Dave d...@looktowindward.com wrote: 1. Is this advisable? Is it Safe? It's kind of weird. I've done it before, and would be surprised if it were unusual. One would often want to seed an app with default and constant data, wouldn't one? — F ___ 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: bugreport.apple.com
On 2 Sep 2013, at 2:31 PM, Fritz Anderson anderson.fr...@gmail.com wrote: On Sep 2, 2013, at 11:48 AM, Todd Heberlein todd_heberl...@mac.com wrote: Off topic, but... Wow! Apple's Bug Reporter has been completely redone. Nice. My compliments to the Apple folks (who I suspect have not had the most relaxing summer) Feeling motivated to file a new report. It sure is purty. Cocoa developers will want to bear in mind for their development practices that the new forms limit text to lengths much, much shorter than what I had found necessary for a useful bug report. Shorter than many posts to this list that draw helpful replies. For instance, it is practically impossible to iterate attempted workarounds and their effect on application state. Iterated NSLog() output (even if cut down to your guess at the relevant items) is out of the question. It may be inadvertent, but it contributes to the cynical (and uninformed) suspicion that Apple never read reports in the first place, so there is no need to let people write long ones. That was the suspicion, and it is not true. To the contrary, I've received direct, generous responses to some reports, based on my having provided enough detail to make the responses possible in the single exchange the respondent had time for. Cocoa developers who prepare bug reports off-line should prioritize the content so at least the most important details of the most important cases make it through. Bear in mind that attempts to reproduce may not make it: If you'd been taking an hour to characterize your bugs, ten minutes is enough to tell Apple what it wants to hear. Limit your instrumentation to what would be relevant to your assumptions about the nature of the bug. If your assumptions are wrong, the time Apple's engineers and you take to reconstruct long-disused projects and turn them around for the next line of investigation will, it seems, be time well-spent. ― F I laid on the snark about two feet too thick. I hope you can take my point if you throttle it back 75%. — F ___ 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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 9:28 AM, Keary Suska cocoa-...@esoteritech.com wrote: On Sep 3, 2013, at 9:27 AM, Steve Mills wrote: We have an NSPanel that doesn't stay stuck to the menubar if you make the screen bigger. If you make the screen smaller, it goes through constrainFrameRect:toScreen and does the right thing. In the nib, the window has the strut set between the screen and window top, and nothing set on the bottom. What's wrong with this thing? It's as if it's stuck to the bottom of the screen instead of the top, and no user thinks that way. Are you simply complaining out loud, or are you unfamiliar with the Cocoa drawing system? If it is the latter, all things will be made clear by reading this doc: Except Steve is right that no user thinks that way, _AND_ he set up the window positioning struts in a way that indicates to him that the window should remain fixed relative to the top edge of the screen. But that’s not what those struts are for. They determine position of the window when it first appears on screen, relative to the position defined in the nib. They don't affect the positioning behavior of the window if the screen resizes. It used to be that windows in Interface Builder were top-level windows on the desktop, rather than drawn on a canvas. The position of the window on screen at design time was encoded in the nib, and that position is where the window would appear by default when the window was unarchived from nib. (It was also a lot more common for windows to be “visible at launch,” especially since NSWindowController didn’t exist.) At some point the springs and struts were added because enough users had differently-sized desktops. The position encoded in nib would be scaled according to the struts. So you could center a window on your screen, unhinge it from all four edges, and the window would appear centered on all your users’s screens. Nowadays, you draw the window on a canvas, so you specify the position of the window by dragging the window proxy in the inspector. Long story short, Steve, the struts aren’t as useful as you think they are. If you're already using a custom view in your status items, you can get the behavior you want by sending -window to the custom view during mouse tracking, and adding your popup window as a child window. --Kyle Sluder ___ 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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 11:28:50, Keary Suska cocoa-...@esoteritech.com wrote: Are you simply complaining out loud, or are you unfamiliar with the Cocoa drawing system? If it is the latter, all things will be made clear by reading this doc: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/CocoaDrawingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40003290-CH201-SW1 I'm asking an actual question. I'm quite familiar with Cocoa's drawing system. This is a question about a window positioning problem. Did you actually read my question? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: bugreport.apple.com
My assumption was that the text limits were instituted so that people would put log statements and all that in attachments instead of the text fields of the bug reporter. On Tue, Sep 3, 2013 at 11:42 AM, Greg Parker gpar...@apple.com wrote: On Sep 2, 2013, at 12:31 PM, Fritz Anderson anderson.fr...@gmail.com wrote: Cocoa developers will want to bear in mind for their development practices that the new forms limit text to lengths much, much shorter than what I had found necessary for a useful bug report. Shorter than many posts to this list that draw helpful replies. For instance, it is practically impossible to iterate attempted workarounds and their effect on application state. Iterated NSLog() output (even if cut down to your guess at the relevant items) is out of the question. That sounds bad. Did you file a bug report? (Yes, usability bugs in the bug reporter should be filed using the bug reporter.) -- 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/alex%40webis.net This email sent to a...@webis.net -- *Alex Kac - **President and Founder* *Web Information Solutions, Inc.* ___ 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: Threadsafe copy of objective c object
On Tue, Sep 3, 2013, at 11:32 AM, Jeff Kelley wrote: Ken is, of course, correct. This is what I get for writing it in my mail client. You’ll want to use dispatch_sync() for reads and dispatch_barrier_async() for writes. …thus defeating the purpose of moving the copy to another thread. --Kyle Sluder ___ 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: Threadsafe copy of objective c object
What I’m surprised no on has mentioned here is the trivial… Remove the mutation methods. Make your object immutable, the referential transparency will give you “free” parallelism. If you want a mutated version of the object, create a new object. Tom Davie ___ 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: NSPanel doesn't reposition correctly after screen resize
On Tue, Sep 3, 2013, at 01:50 PM, Steve Mills wrote: On Sep 3, 2013, at 15:34:25, Lee Ann Rucker lruc...@vmware.com wrote: NSApplicationDidChangeScreenParametersNotification It doesn't have userInfo, so you'll still have to save the last known screen bounds yourself. Hmm. This seems no different than the NSWindowDidChangeScreenNotification other than it's app-centric rather than affecting each actual window. Not all that helpful really. How does Apple do it? They obviously have to move the windows to keep them relative to the top of the screen, to deal with the dopey bottom-up coordinate system they went with. They probably listen for that notification, then compare the size of the -screen of the window they're trying to position to its previously known size. --Kyle Sluder ___ 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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 1:50 PM, Steve Mills wrote: On Sep 3, 2013, at 15:34:25, Lee Ann Rucker lruc...@vmware.com wrote: NSApplicationDidChangeScreenParametersNotification It doesn't have userInfo, so you'll still have to save the last known screen bounds yourself. Hmm. This seems no different than the NSWindowDidChangeScreenNotification other than it's app-centric rather than affecting each actual window. Not all that helpful really. NSWindowDidChangeScreenNotification is sent when the window moves to another screen. NSApplicationDidChangeScreenParametersNotification is when the screen itself changes. You'll probably have to listen to both of them, but they can share code. How does Apple do it? They obviously have to move the windows to keep them relative to the top of the screen, to deal with the dopey bottom-up coordinate system they went with. If you look at the result of stringWithSavedFrame, it includes the window's screen frame. This is how restoration (old and new) adjusts when a window restores to a different screen configuration. It wouldn't surprise me if they're keeping the screen frame saved somewhere internally too. ___ 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: Threadsafe copy of objective c object
On Tue, Sep 3, 2013, at 07:29 AM, David Duncan wrote: On Sep 3, 2013, at 5:39 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: I would like to be able to take a copy of MyParameters from a thread that is not the main thread Why? Sure, you have a thread doing real-time video processing, but how expensive can it be to make a copy and send it over? Audio Units basically do this and they are just as real-time. One of the cardinal rules of Audio Units is Thou Shalt Not Allocate Memory On The Render Callback Thread. malloc takes a lock. Taking a lock is a great way to make you thread miss its hard-realtime constraint, which leads to glitching and potentially getting killed by the host. The typical way to do this is to perform your allocations and copies on a NON-realtime thread, and transfer ownership of data to your render thread via a lockless data structure such as a ring buffer. Your realtime thread runs for very brief periods, consuming one or two chunks of data, while your non-realtime thread runs more sporadically but for much longer periods of time, hopefully often enough to keep up with the realtime thread's consumption of data. --Kyle Sluder ___ 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: Threadsafe copy of objective c object
On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
You can't use dispatch_async() for this. It has to be synchronous, since
you're returning the value that's going to be set.
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
Same here.
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Regards,
Ken
___
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: NSPanel doesn't reposition correctly after screen resize
NSApplicationDidChangeScreenParametersNotification It doesn't have userInfo, so you'll still have to save the last known screen bounds yourself. On Sep 3, 2013, at 12:57 PM, Steve Mills wrote: Aha, I just found this in the docs for isMovable: A non-movable window will not be moved or resized by the system in response to a display reconfiguration. (I was looking for something about this in setIsMovable, which is where I expect key information like this to be mentioned, since that's the thing developers might be calling to set the behavior.) So, looks like I need to handle screen resizes myself, along with restoring a window on a different screen than it was saved on. I don't see any notifications that look like NSWindowScreenSizeDidChange. Where would I catch these window is moving because the screen changed size messages? I tried adding a NSWindowDidChangeScreenNotification handler, which *does* get called when changing a screen's size, but the notification doesn't contain the old screen size, so I can't move it appropriately. Arg. There's no accompanying NSWindowWillChangeScreenNotification in which to store the old screen size. I'm out of ideas for something that should be really simple. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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/lrucker%40vmware.com This email sent to lruc...@vmware.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
Re: Threadsafe copy of objective c object
Ken is, of course, correct. This is what I get for writing it in my mail
client.
You’ll want to use dispatch_sync() for reads and dispatch_barrier_async()
for writes.
Jeff Kelley
On Tue, Sep 3, 2013 at 2:30 PM, Ken Thomases k...@codeweavers.com wrote:
On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
You can't use dispatch_async() for this. It has to be synchronous, since
you're returning the value that's going to be set.
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
Same here.
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Regards,
Ken
___
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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 15:34:25, Lee Ann Rucker lruc...@vmware.com wrote: NSApplicationDidChangeScreenParametersNotification It doesn't have userInfo, so you'll still have to save the last known screen bounds yourself. Hmm. This seems no different than the NSWindowDidChangeScreenNotification other than it's app-centric rather than affecting each actual window. Not all that helpful really. How does Apple do it? They obviously have to move the windows to keep them relative to the top of the screen, to deal with the dopey bottom-up coordinate system they went with. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Experience with keyed archiving forward/backwards compatibility?
On 2 Sep 2013, at 12:47 AM, Marcel Weiher marcel.wei...@gmail.com wrote: This gets (mis-)quoted out of context way too much (my emphasis): We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil” It goes on as follows: Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only ***after*** that code has been identified. It is often a mistake to make ***a priori*** judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. ... [Emphases added. I hope the edits do not misrepresent your position.] This is wisdom. But the aphorism is not in even rhetorical opposition to — it is a reinforcement of — what Knuth restated at length. The key word is _premature_, doing what should be done **after**, not to be done **a priori**. The opposition (Yet...), if any, is against taking the aphorism as an absolute, ignoring that it warns of prematurity, not optimization or instrumentation. Everybody who quotes it understands that, and joins Knuth in demanding measurement before jumping to conclusions — which are almost always wrong. And premature. I confess I am sheepish about applying Talmudic exegesis to what are after all only the opinions of one man, however distinguished. The appropriate issue is not what his opinions are (were? I hope not), but what is the best practice. — F ___ 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
NSPanel doesn't reposition correctly after screen resize
We have an NSPanel that doesn't stay stuck to the menubar if you make the screen bigger. If you make the screen smaller, it goes through constrainFrameRect:toScreen and does the right thing. In the nib, the window has the strut set between the screen and window top, and nothing set on the bottom. What's wrong with this thing? It's as if it's stuck to the bottom of the screen instead of the top, and no user thinks that way. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: NSPanel doesn't reposition correctly after screen resize
Aha, I just found this in the docs for isMovable: A non-movable window will not be moved or resized by the system in response to a display reconfiguration. (I was looking for something about this in setIsMovable, which is where I expect key information like this to be mentioned, since that's the thing developers might be calling to set the behavior.) So, looks like I need to handle screen resizes myself, along with restoring a window on a different screen than it was saved on. I don't see any notifications that look like NSWindowScreenSizeDidChange. Where would I catch these window is moving because the screen changed size messages? I tried adding a NSWindowDidChangeScreenNotification handler, which *does* get called when changing a screen's size, but the notification doesn't contain the old screen size, so I can't move it appropriately. Arg. There's no accompanying NSWindowWillChangeScreenNotification in which to store the old screen size. I'm out of ideas for something that should be really simple. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 9:27 AM, Steve Mills wrote: We have an NSPanel that doesn't stay stuck to the menubar if you make the screen bigger. If you make the screen smaller, it goes through constrainFrameRect:toScreen and does the right thing. In the nib, the window has the strut set between the screen and window top, and nothing set on the bottom. What's wrong with this thing? It's as if it's stuck to the bottom of the screen instead of the top, and no user thinks that way. Are you simply complaining out loud, or are you unfamiliar with the Cocoa drawing system? If it is the latter, all things will be made clear by reading this doc: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/CocoaDrawingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40003290-CH201-SW1 Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: NSPanel doesn't reposition correctly after screen resize
On Sep 3, 2013, at 12:16:23, Kyle Sluder k...@ksluder.com wrote: Long story short, Steve, the struts aren’t as useful as you think they are. If you're already using a custom view in your status items, you can get the behavior you want by sending -window to the custom view during mouse tracking, and adding your popup window as a child window. Thanks for addressing the actual question, Kyle, and for the info about the struts being useless in this case (we programmatically position it to the default position, then it gets restored to the last known position, or something like that). This isn't a popup window - you might be thinking of an earlier problem I was working on. This is just a palette that floats onscreen, most often positioned right beneath the menubar. It has setMovable set to NO, because we need to handle window snapping when the user drags the window, but that doesn't affect how the window moves programmatically (or at least the docs say can be dragged by clicking in its title bar or background). constrainFrameRect:toScreen: is overridden, but it simply calls super if the app is not in fullscreen mode. Our document window is having the same problem when changing screen sizes. Both also position incorrectly upon restoration if the app is being run on a different screen size than when it last quit. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Threadsafe copy of objective c object
On Sep 3, 2013, at 3:52 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. This doesn’t have anything to do with atomic properties — all that keyword does is ensure that the property’s synthesized accessor methods are thread-safe with respect to the property value. It doesn’t help at all if you’re considering the object as a whole — you can access property a and then property b and get valid values for both, but they might not be consistent with each other because they were accessed at different times. If you want to look at the object as a whole you have to use some higher-level locking to keep it from being mutated while you work on it. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. No, you’re responsible for implementing -copy yourself. The base implementation in NSObject doesn’t copy any fields or properties implemented in subclasses. Is there any way, then, that I can take a copy in a threadsafe manner? If the object is mutable, you have to synchronize every method that can alter its state, probably using @synchronized(self). This means you can’t use synthesized property setters. Then synchronize the copy method the same way. This is one reason why concurrent programming often relies on immutable objects — because they can be passed around multiple threads safely. Thread-safe access to mutable objects is a real pain and it’s very easy to create subtle bugs that only show up very rarely. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: bugreport.apple.com
On Sep 2, 2013, at 12:31 PM, Fritz Anderson anderson.fr...@gmail.com wrote: Cocoa developers will want to bear in mind for their development practices that the new forms limit text to lengths much, much shorter than what I had found necessary for a useful bug report. Shorter than many posts to this list that draw helpful replies. For instance, it is practically impossible to iterate attempted workarounds and their effect on application state. Iterated NSLog() output (even if cut down to your guess at the relevant items) is out of the question. That sounds bad. Did you file a bug report? (Yes, usability bugs in the bug reporter should be filed using the bug reporter.) -- 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
