performSlectorOnMainThread still exists. Although I'm re-writing my app from
the ground up, I'm posting an interim release which will continue to use this
approach. The behaviors between the OSes are different, and I was looking for
some indication as to why.
On Feb 14, 2014, at 11:32 , Fritz A
On 12 Feb 2014, at 1:29 PM, Rick Mann wrote:
> I think you misunderstand my question. I know about the new concurrency
> types. I'm not interested in that. I want to know why my old code works
> better on iOS 7 than 6.
Given that the new concurrency method goes back a couple of years (iOS 5),
On Feb 12, 2014, at 07:58 , Fritz Anderson wrote:
> On 11 Feb 2014, at 6:04 PM, Rick Mann wrote:
>
>> I'm updating an old project that was built long ago, skipping udpates for
>> iOS 5 & 6. One of the things my app does, in an NSOperation, is call
>> -perf
On 11 Feb 2014, at 6:04 PM, Rick Mann wrote:
> I'm updating an old project that was built long ago, skipping udpates for iOS
> 5 & 6. One of the things my app does, in an NSOperation, is call
> -performSelectorOnMainThread: (waiting until done) as it integrates
> download
I'm updating an old project that was built long ago, skipping udpates for iOS 5
& 6. One of the things my app does, in an NSOperation, is call
-performSelectorOnMainThread: (waiting until done) as it integrates downloaded
data into the Core Data store (Core Data operations all happ
At 8:13 AM -0800 2/5/13, Glenn L. Austin wrote:
I understand the *reasoning* behind
performSelector:withObject:afterDelay:, but I've banned that from
code I work on.
In the OP's case, I think he just needs to perform the selector
asynchronously so he doesn't deadlock -- waitUntilDone:NO ought
On Feb 4, 2013, at 8:58 AM, Kyle Sluder wrote:
> On Sun, Feb 3, 2013, at 11:58 PM, 尹佳冀 wrote:
>> Thanks Mike seem You are right, and I write like this
>>
>> [self performSelector:@selector(doTheThing) withObject:nil
>> afterDelay:0.5];
>> it can work correctly.
>
> Magic constants like this ar
UD not show
>
> > //[self performSelectorOnMainThread:@selector(doTheThing)
> > withObject:nil waitUntilDone:YES];
to ... waitUntilDone:NO... it will work as well.
It's hard to tell what's going on without looking
at more of your code, but this smells a lo
On Sun, Feb 3, 2013, at 11:58 PM, 尹佳冀 wrote:
> Thanks Mike seem You are right, and I write like this
>
> [self performSelector:@selector(doTheThing) withObject:nil
> afterDelay:0.5];
> it can work correctly.
Magic constants like this are evil and are a serious indicator of poor
programming practi
; > Does anyone can know what the difference between [NSOperationQueue
> > currentQueue] and
> > performSelectorOnMainThread, If I do some work use operation
> > on [NSOperationQueue mainQueue], the UI will not hang up, but if i
> > use performSelectorOnMainThr
On 3 Feb 2013, at 07:41, 尹佳冀 wrote:
> Hi All
>
> Does anyone can know what the difference between [NSOperationQueue
> currentQueue] and
> performSelectorOnMainThread, If I do some work use operation
> on [NSOperationQueue mainQueue], the UI will not hang
Hi All
Does anyone can know what the difference between [NSOperationQueue
currentQueue] and
performSelectorOnMainThread, If I do some work use operation
on [NSOperationQueue mainQueue], the UI will not hang up, but if i
use performSelectorOnMainThread the UI will hang up
- (void) doTheThing
run loop. Since -performSelectorOnMainThread
relies on that reference, calls to -performSelectorOnMainThread fail.
Both issues seem to involve bad timing in the use of certain Cocoa
APIs; it seems there's something about the order and timing of
Gideon's project that's causing NSThread to think tha
t in my test app and the calls to
-performSelectorOnMainThread seem to work fine.
___
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/Uns
On Wed, Dec 8, 2010 at 4:30 AM, Gideon King wrote:
> So could this issue be something to do with the timing of the first time the
> threaded operation is run?
>
> During startup of the application, in an awakeFromNib, it calls a
> performSelector...afterDelay:0, and when that eventually fires, i
On Dec 8, 2010, at 6:30 AM, Gideon King wrote:
> So could this issue be something to do with the timing of the first time the
> threaded operation is run?
>
> During startup of the application, in an awakeFromNib, it calls a
> performSelector...afterDelay:0, and when that eventually fires, it
would be perfectly safe, but maybe not?
Thanks
Gideon
On 08/12/2010, at 10:02 PM, Dave Keck wrote:
>
> 4. Does -performSelectorOnMainThread work if you call [NSThread
> mainThread] as the first line in main()?
___
Cocoa-dev mailing list (
t; Cocoa/NSThread APIs safely together.
>
> 2. Do you have any functions marked __attribute__ ((constructor)) ?
>
> 3. What does your main() function look like?
>
> 4. Does -performSelectorOnMainThread work if you call [NSThread
> mainThread] as the first line in main()?
__
ion certain
considerations that have to be made to use the pthread and
Cocoa/NSThread APIs safely together.
2. Do you have any functions marked __attribute__ ((constructor)) ?
3. What does your main() function look like?
4. Does -performSelectorOnMainThread work if you call [NSThread
mainThread]
On 8 Dec 2010, at 11:43, Gideon King wrote:
> 0x114400a60 ?== 0x1029006e0
>
> Assertion fails. The two are completely different as per previous results.
>
> FYI, I do not create any run loops explicitly in my application, and can't
> think of anything I am doing which would create one implicit
Dave Keck wrote:
>> You are correct. They are two different things:
>
> Alright, does the following assertion fail when placed before the
> -performSelectorOnMainThread line? (Ignore the warning - using private
> APIs.)
>
>id a = (id)[[[NSThread mainThread] runLoop] g
> You are correct. They are two different things:
Alright, does the following assertion fail when placed before the
-performSelectorOnMainThread line? (Ignore the warning - using private
APIs.)
id a = (id)[[[NSThread mainThread] runLoop] getCFRunLoop];
id b = (id)CFRunLoopGetM
TrackingRunLoopMode"}
2 : {contents =
"kCFRunLoopDefaultMode"}
}
...
Thanks for offering to look into this further.
Gideon
On 08/12/2010, at 8:16 PM, Dave Keck wrote:
>> That was the output for $rdi at the CGRunLoopWakeUp breakpoint immediately
>> after the c
Thanks Jonathan, but that's exactly what I did, and I couldn't replicate the
problem in my test project, which is why I'm saying that something outside the
multithreading is screwing things up somehow, but that could be anywhere in
23,000 lines of code, and I don't know what to look for. This is
> That was the output for $rdi at the CGRunLoopWakeUp breakpoint immediately
> after the call to performSelectorOnMainThread...
Sorry, realized that after I sent. The output still isn't what I would
expect though: on my system, the run loop supplied to
CFRunLoopWakeUp() from
On 8 Dec 2010, at 08:57, Gideon King wrote:
> That was the output for $rdi at the CGRunLoopWakeUp breakpoint immediately
> after the call to performSelectorOnMainThread...
>
> The output of po (void*)CFRunLoopGetMain() on the line after that is
> http://pastie.org/1358258
&g
That was the output for $rdi at the CGRunLoopWakeUp breakpoint immediately
after the call to performSelectorOnMainThread...
The output of po (void*)CFRunLoopGetMain() on the line after that is
http://pastie.org/1358258
When I print $rdi at the CGRunLoopWakeUp in my mini test application, I do
you entered:
po (void*)CFRunLoopGetMain()
and not:
po (void*)CFRunLoopGetCurrent()
? To clarify:
[anObject performSelectorOnMainThread: ...]
NSLog(@"Breakpoint line"); // <-- set breakpoint here
On my machine, if I set a breakpoint on the NSLog line and upon
hitting it,
> {locked = false, wakeup port = 0x5a03,
> stopped = false,
> current mode = (none),
> common modes = {type = mutable set,
> count = 1,
> entries =>
> 1 : {contents = "kCFRunLoopDefaultMode"}
> }
> ,
> common mode items = {type = mutable set,
> count = 1,
> entries =>
> 25 : {locked = No, signalled
On 08/12/2010, at 4:19 PM, Dave Keck wrote:
>
> 1. Place a breakpoint on the line after the call to
> -performSelectorOnMainThread. After this is hit, at the GDB prompt,
> enter the following command:
>
>po (void*)CFRunLoopGetMain()
>
> This should print a lot
> 3. Stop your program, and set a breakpoint on the
> -performSelectorOnMainThread line. Run your program again. When this
> breakpoint is hit, before continuing your program, set a breakpoint at
> CFRunLoopSourceSignal(). Continue your program. The
> CFRunLoopSourceSignal breakpoin
icious of that. Should that kill any
> application?
No, it shouldn't make your app terminate - it'll just cause
CFRunLoopRunInMode() to return (see the stack trace you posted
earlier.) I was thinking this would cause the
-performSelectorOnMainThread machinery to notice that there wa
I have copied the source code to a different computer, and can confirm that it
made no difference - the behaviour is the same.
Regards
Gideon
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comm
ons though...
Gideon
On 08/12/2010, at 2:36 PM, Dave Keck wrote:
> Some thoughts:
>
> 1. What happens if you specify a different object to receive the
> message? For example, try [NSApp performSelectorOnMainThread:
> @selector(terminate:) ... waitUntilDone: YES]. Does your app
>
Also: a quick peek at the assembly of -performSelectorOnMainThread:
reveals that it calls _CFExecutableLinkedOnOrAfter(). Presumably this
is to modify its behavior based on what SDK your app links against;
perhaps changing your Base SDK has an effect
Some thoughts:
1. What happens if you specify a different object to receive the
message? For example, try [NSApp performSelectorOnMainThread:
@selector(terminate:) ... waitUntilDone: YES]. Does your app
terminate?
2. Specify waitUntilDone: NO, and after the call to
-performSelectorOnMainThread
[pool release];
}
- (void)innerExecute:(AADataForLayoutProcess *)data {
[self performSelectorOnMainThread:@selector(callback) withObject:nil
waitUntilDone:NO];
}
- (void)callback {
NSLog(@"Called back from thread");
}
At this stage, I'm pretty sure that something oth
> Any ideas?
Post your code!
___
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 Subscri
I have completely commented out all the actions of the method that is executing
in the thread. The only things it does are to create an autorelease pool, call
a simple performSelectorOnMainThread, and release the pool. There is nothing
else going on that I can see, and yet it still fails as per
Good thought thanks Charles, but everything else seems to be responding as
usual. No spinning wheel, still able to do other things in the UI. Main thread
trace says:
#0 0x9546b0fa in mach_msg_trap ()
#1 0x9546b867 in mach_msg ()
#2 0x9212d37f in __CFRunLoopRun ()
#3 0x9212c464 in CFRunLoopRu
On Dec 7, 2010, at 2:19 PM, Gideon King wrote:
> Another data point on this: if I use waitUntilDone:NO, it doesn't even work
> the first time through.
>
> Responds to selector still returns YES. There are no error messages.
Is something tying up the main thread? It won’t execute your request if
at I run in a
> separate thread, and right at the end of the method, I call
>
> [anObject performSelectorOnMainThread:@selector(myMethod:)
> withObject:someData waitUntilDone:YES];
>
> This works fine the first time I run it. The second and subsequent times I
> try it
Hi, I'm trying to debug a really odd issue. I have a method that I run in a
separate thread, and right at the end of the method, I call
[anObject performSelectorOnMainThread:@selector(myMethod:)
withObject:someData waitUntilDone:YES];
This works fine the first time I run it
On Thu, May 28, 2009 at 4:53 PM, Erg Consultant
wrote:
> Either your main thread doesn't implement the selector requested, or else
> it's an issue with the runloop never processing the request. If you have code
> that alters the runloop or modifies its input sources, check that code first.
Thre
nstein
To: cocoa-dev@lists.apple.com
Sent: Thursday, May 28, 2009 9:11:42 AM
Subject: performSelectorOnMainThread problem
Does anyone know of any issue that would cause performSelectorOnMainThread to
not actually perform the selector but not report any kind of error? I use
threads very often and
Well at the time I wrote that, I thought it was sitting completely
idle, but it seems the NSManagedObjectContext lock was blocking the
main thread, even my application is specifically designed to not do
that. It's working okay now...
Thanks,
Ben
On May 28, 2009, at 1:51 PM, Shawn Erickson
On Thu, May 28, 2009 at 9:46 AM, Ben Einstein wrote:
>> (2) The main run loop is not running for some reason.
>
> The main run loop is waiting to hear back from the completion of the worker
What do you mean by "waiting"? Is it blocked on something?
-Shawn
___
On May 28, 2009, at 12:13 PM, Ben Einstein wrote:
Thanks for the advice, I had actually tried that as well to no avail.
After playing around a bit, I'm fairly certain I've solved it,
although I'm not really sure why it was a problem. At the top of the
worker method, I was locking the NSMan
Thanks for the advice, I had actually tried that as well to no avail.
After playing around a bit, I'm fairly certain I've solved it,
although I'm not really sure why it was a problem. At the top of the
worker method, I was locking the NSManagedObjectContext and unlocking
it just before retu
On May 28, 2009, at 9:46 AM, Ben Einstein wrote:
On May 28, 2009, at 12:36 PM, Jeff Johnson wrote:
Three general possibilities:
(1) aControllerObject is nil.
Definitely not the problem because it works when calling
performSelector: without the mainThread part.
(2) The main run loop i
On May 28, 2009, at 12:36 PM, Jeff Johnson wrote:
Three general possibilities:
(1) aControllerObject is nil.
Definitely not the problem because it works when calling
performSelector: without the mainThread part.
(2) The main run loop is not running for some reason.
The main run loop i
tein wrote:
Does anyone know of any issue that would cause
performSelectorOnMainThread to not actually perform the selector but
not report any kind of error? I use threads very often and have
never had a problem like this, but when I call:
[aControllerObject
performSelectorOnMainThread
On May 28, 2009, at 10:11 AM, Ben Einstein wrote:
Does anyone know of any issue that would cause
performSelectorOnMainThread to not actually perform the selector but
not report any kind of error?
Are you sure the main thread isn't busy and is running a run loop in
its default
Does anyone know of any issue that would cause
performSelectorOnMainThread to not actually perform the selector but
not report any kind of error? I use threads very often and have never
had a problem like this, but when I call:
[aControllerObject performSelectorOnMainThread:@selector
On Wed, May 6, 2009 at 3:13 AM, Martin F. Carianni
wrote:
> Hello, i'm having some trouble with CFRunLoop, and
> performSelectorOnMainThread. I've a CFFTP client (with a latter COCOA
> implementation to interface with the GUI-class) which needs to pass a
> directory listing
Hello, i'm having some trouble with CFRunLoop, and
performSelectorOnMainThread. I've a CFFTP client (with a latter COCOA
implementation to interface with the GUI-class) which needs to pass a
directory listing array to the GUI. But when I try to send the array
object via a
ust had the idea to add an un-boxed version of
performSelectorOnMainThread to NSObject via Category.
But could you elaborate on the HOM a bit. Not sure I can follow there.
cheers
--
Torsten
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do n
Value: (id) value
{
[self setValue: value forKey: @"activated"];
}
OR, in your thread:
[view performSelectorOnMainThread:
@selector(setValuesForKeysWithDictionary:) withObject: [NSDictionary
dictionaryWithObjectsAndKeys: [NSNumber numberWithBool:YES],
@"activated",nil] wai
Is this supposed to work or not?
- (void) setActivated:(BOOL)theStatus;
[view performSelectorOnMainThread:@selector(setActivated:)
withObject:[NSNumber numberWithBool:YES] waitUntilDone:YES];
This won't work since the boolean isn't auto-unboxed. Your method
should accept a
On Wed, Apr 22, 2009 at 12:13 PM, Torsten Curdt wrote:
> Hey folks,
>
> Is this supposed to work or not?
>
> - (void) setActivated:(BOOL)theStatus;
>
> [view performSelectorOnMainThread:@selector(setActivated:)
> withObject:[NSNumber numberWithBool:YES] waitUntilDone:YE
On Apr 22, 2009, at 11:13 AM, Torsten Curdt wrote:
Is this supposed to work or not?
- (void) setActivated:(BOOL)theStatus;
[view performSelectorOnMainThread:@selector(setActivated:)
withObject:[NSNumber numberWithBool:YES] waitUntilDone:YES];
It does not seem like it works that way.
No
vated:(BOOL)theStatus;
[view performSelectorOnMainThread:@selector(setActivated:)
withObject:[NSNumber numberWithBool:YES] waitUntilDone:YES];
It does not seem like it works that way.
Do I really have to use NSInvocation for this?
cheers
--
To
Hey folks,
Is this supposed to work or not?
- (void) setActivated:(BOOL)theStatus;
[view performSelectorOnMainThread:@selector(setActivated:)
withObject:[NSNumber numberWithBool:YES] waitUntilDone:YES];
It does not seem like it works that way.
Do I really have to use NSInvocation for this
ifies as
> in-significant. Given that assumption, my real question is how to implement
> it. I call:
>
> [self performSelectorOnMainThread:@selector:mySimpleSelector withObject:nil
> waitUntilDone:YES];
>
> (int) mySimpleSelector {
>if (whatever) return 0;
>
Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via
nt. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via
nt. Given that assumption, my real question is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via
ment it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimpleSelector's returne
is how to
implement it. I call:
[self performSelectorOnMainThread:@selector:mySimpleSelector
withObject:nil waitUntilDone:YES];
(int) mySimpleSelector {
if (whatever) return 0;
else return 1;
}
via my call to -performSelectorOnMainThread, just how do I access -
mySimple
At 6:51 PM -0500 10/27/08, Ken Thomases wrote:
On Oct 27, 2008, at 4:05 PM, [EMAIL PROTECTED] wrote:
if i call -[anObject performSelectorOnMainThread:aSelector
withObject:nil waitUntilDone:NO] and then later throw an exception
(of my own), which i catch, the deferred execution of aSelector
ne
At 6:51 PM -0500 10/27/08, Ken Thomases wrote:
On Oct 27, 2008, at 4:05 PM, [EMAIL PROTECTED] wrote:
if i call -[anObject performSelectorOnMainThread:aSelector
withObject:nil waitUntilDone:NO] and then later throw an exception
(of my own), which i catch, the deferred execution of aSelector
ne
On Oct 27, 2008, at 4:05 PM, [EMAIL PROTECTED] wrote:
if i call -[anObject performSelectorOnMainThread:aSelector
withObject:nil waitUntilDone:NO] and then later throw an exception
(of my own), which i catch, the deferred execution of aSelector
never happens. note that the performSelectonOnM
if i call -[anObject performSelectorOnMainThread:aSelector
withObject:nil waitUntilDone:NO] and then later throw an exception
(of my own), which i catch, the deferred execution of aSelector never
happens. note that the performSelectonOnMainThread, and the throw and
catch are all in the same run
You appear to have declared updateAirDate: to be an instance method,
but you're sending the message to the class. You want something more
like
[appDelegate performSelectorOnMainThread:@selector(updateAirDate:)
withObject:airDate waitUntilDone:NO];
where appDelegate is the rel
Greetings.
I need to gain a better understanding of performSelectorOnMainThread
I have my main window that had a delegate and the delegate spawns
threads, once the threads(NSOperation) are done they return a string,
I use to do it thru a delegate but Core Data does not appreciate
multiple
Le 7 avr. 08 à 16:49, Jens Alfke a écrit :
On 7 Apr '08, at 6:24 AM, Jacob Engstrand wrote:
In a separate thread I call:
[self performSelectorOnMainThread: @selector(broadcastMessage:)
withObject: nil waitUntilDone: NO];
Now, is there a way for the main thread to inspect the que
On 7 Apr '08, at 6:24 AM, Jacob Engstrand wrote:
In a separate thread I call:
[self performSelectorOnMainThread: @selector(broadcastMessage:)
withObject: nil waitUntilDone: NO];
Now, is there a way for the main thread to inspect the queue of
pending messages, their targets and argu
Hi all,
In a separate thread I call:
[self performSelectorOnMainThread: @selector(broadcastMessage:)
withObject: nil waitUntilDone: NO];
Now, is there a way for the main thread to inspect the queue of
pending messages, their targets and arguments?
(I would like my unit test to verify that
On 13.03.2008, at 02:27, Nick Rogers wrote:
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@selector(updateProgress)
withObject:data waitUntilDone:YES];
with the error that self does not recognize the selector
updateProgress.
I have imported the main AppControl
#x27;re calling
performSelectorOnMainThreadFrom? That's what you're saying by passing
self.
If not, you need to refer to the class/object it's in. So, if
"updateProgress:" is defined in your app controller and you have a
reference to that, you might do something like:
[m_app
n Stiles wrote:
If -updateProgress is taking "data" as an argument, then you
probably want
@selector(updateProgress:)
Note the colon.
Nick Rogers wrote:
Hi,
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@selector(updateProgress)
withObject:
n 13-Mar-08, at 7:00 AM, John Stiles wrote:
If -updateProgress is taking "data" as an argument, then you probably
want
@selector(updateProgress:)
Note the colon.
Nick Rogers wrote:
Hi,
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@select
wrote:
Hi,
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@selector(updateProgress)
withObject:data waitUntilDone:YES];
with the error that self does not recognize the selector
updateProgress.
I have imported the main AppController.h into this secondary class
fil
If -updateProgress is taking "data" as an argument, then you probably want
@selector(updateProgress:)
Note the colon.
Nick Rogers wrote:
Hi,
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@selector(updateProgress)
withObject:data waitUntilDone:YES];
Hi,
In my secondary thread I'm doing:
[self performSelectorOnMainThread:@selector(updateProgress)
withObject:data waitUntilDone:YES];
with the error that self does not recognize the selector updateProgress.
I have imported the main AppController.h into this secondary class
file. stil
On Thu, Feb 28, 2008 at 10:48 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> The documentation explicitly describes -[NSObject
> performSelectorOnMainThread:withObject:waitUntilDone:] as queueing and
> dequeueing selectors on the main thread. It seems reasonable to
> assume they're not outright
On Thu, Feb 28, 2008 at 5:31 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
>
> However, there is no equivalent promise in Apple's documentation for
> NSObject; it is conspicuous in its absence. Can anyone confirm or deny
> that it has the same behaviour as in GNUstep?
The documentation explicitly
Hi,
The GNUstep documentation for the
NSObject(NSMainThreadPerformAdditions) category states the following
for performSelectorOnMainThread: withObject: waitUntilDone: modes:
"Where this method has been called more than once before the runloop
of the main thread runs in the required mode
88 matches
Mail list logo
