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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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
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]
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?
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
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
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:
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
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.
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
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
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
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
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;
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
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
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
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:
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
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
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
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
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,
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
38 matches
Mail list logo
