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
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
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 tha
> 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 nee
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
ac
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 s
On 03/09/2013, at 1:23 PM, Jonathan Taylor
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'
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 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
> 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 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
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
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 basi
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 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 wrote:
>
>> 1. Is this advisable? Is it Safe?
>
> It's kind of wei
On 2 Sep 2013, at 2:31 PM, Fritz Anderson wrote:
> On Sep 2, 2013, at 11:48 AM, Todd Heberlein 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)
>>
>> Feelin
On Sep 3, 2013, at 9:28 AM, Keary Suska 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 thi
On Sep 3, 2013, at 11:28:50, Keary Suska 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/Cocoa
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 wrote:
> On Sep 2, 2013, at 12:31 PM, Fritz Anderson
> wrote:
> > Cocoa develo
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 wrote:
>
> > NSApplicationDidChangeScreenParametersNotification
> >
> > It doesn't have userInfo, so you'll still have to save the last known
> > screen bounds yourself.
>
> Hmm. This seems no di
On Sep 3, 2013, at 1:50 PM, Steve Mills wrote:
> On Sep 3, 2013, at 15:34:25, Lee Ann Rucker 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
On Tue, Sep 3, 2013, at 07:29 AM, David Duncan wrote:
> On Sep 3, 2013, at 5:39 AM, Jonathan Taylor
> 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
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 resiz
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 wrote:
> On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
>
> > You cou
On Sep 3, 2013, at 15:34:25, Lee Ann Rucker 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
On 2 Sep 2013, at 12:47 AM, Marcel Weiher 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
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
botto
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
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
On Sep 3, 2013, at 12:16:23, Kyle Sluder 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 add
On Sep 3, 2013, at 3:52 AM, Jonathan Taylor
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
On Sep 2, 2013, at 12:31 PM, Fritz Anderson 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 dr
38 matches
Mail list logo
