drawRect runs twice, bounds are changed in between
In my simple test project, an NSBezierPath is created and stroked.
-(id)initWithCoder:(NSCoder*)coder{
_path = [[NSBezierPath alloc] init];
create points
}
- (void)drawRect:(NSRect)dirtyRect {
bounds = [self bounds];
NSLog(@\n\n bounds: %@\n\n, NSStringFromRect(bounds));
[[NSColor whiteColor] set];
[_path setLineWidth:07.0];//default width = 1
[_path stroke];
bounds = [self bounds];
NSLog(@\n\n emd bounds: %@\n\n, NSStringFromRect(bounds));
}
A breakpoint at the end of drawRect shows that it runs twice. After the second
pass, the view appears, as it should.
Between passes, bounds is changed somehow, as shown by NSLog at the start and
end of drawRect.
Since this will upset code that I will add later, I’d like to stop this.
_path is not changed in either pass.
needsToDrawRect: is not used.
I’m using Xcode 6.1.1 in OSX 10.9.5.
I have not been able to find a reason for this behavior. . I don’t know how to
reveal the point between passes where bounds is actually changed. It does not
happen in any other NSView projects of mine; drawRect runs only once in them
I would like to prevent the second pass, or at least prevent the bounds change
between passes. I’m reluctant to try restoring bounds to its first value. I
appreciate Ken Thomases’ warning in a previous subject not to change bounds in
drawRect.
Can anyone explain why this happens? Is it possible to suppress it without
destroying whatever good it does?
Thanks,
Nick
___
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: NSThread
I am using all this good advice to attempt to unwrap myself and the axle. I shall return. -rags On Jan 13, 2015, at 2:09 PM, Corbin Dunn corb...@apple.com wrote: On Jan 13, 2015, at 9:57 AM, Mike Abdullah mabdul...@karelia.com wrote: On 13 Jan 2015, at 16:18, Mike Abdullah mabdul...@karelia.com wrote: On 13 Jan 2015, at 16:07, Raglan T. Tiger r...@crusaderrabbit.net wrote: I allocate and init an NSThread as follows: if ( m_mythread ) [m_mythread cancel]; m_mythread = [[MYThread alloc] initWithTarget:m_mythread selector:@selector(start) object:m_anobject]; [m_mythread start]; Looking closer, I have to wonder what you think this code will do. You seem to be trying to create a thread that will message *itself* to do its work. Not only that, but I bet it infinite loops restarting itself. 1. Use init, not initWithTarget. 2. Override -main to do your threaded work. corbin At the time this code is executed, m_mythread will either be nil, or will point to an older thread instance that you’re about to supersede. I think you need to take a step back and evaluate your app design. What are you actually trying to accomplish here? Would using NSOperationQueue or GCD better suit your needs? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com mailto: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 http://lists.apple.com/ Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com This email sent to corb...@apple.com mailto:corb...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com mailto: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 http://lists.apple.com/ Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net https://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net This email sent to k...@highrolls.net mailto:k...@highrolls.net ___ 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: NSThread
On Jan 13, 2015, at 9:18 AM, Mike Abdullah mabdul...@karelia.com wrote: Step 1 of diagnosis: take a sample. How would that be accomplished ? -rags ___ 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: NSThread
On 13 Jan 2015, at 16:18, Mike Abdullah mabdul...@karelia.com wrote: On 13 Jan 2015, at 16:07, Raglan T. Tiger r...@crusaderrabbit.net wrote: I allocate and init an NSThread as follows: if ( m_mythread ) [m_mythread cancel]; m_mythread = [[MYThread alloc] initWithTarget:m_mythread selector:@selector(start) object:m_anobject]; [m_mythread start]; Looking closer, I have to wonder what you think this code will do. You seem to be trying to create a thread that will message *itself* to do its work. At the time this code is executed, m_mythread will either be nil, or will point to an older thread instance that you’re about to supersede. I think you need to take a step back and evaluate your app design. What are you actually trying to accomplish here? Would using NSOperationQueue or GCD better suit your needs? ___ 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: NSThread
On 13 Jan 2015, at 17:50, Raglan T. Tiger r...@crusaderrabbit.net wrote: On Jan 13, 2015, at 9:18 AM, Mike Abdullah mabdul...@karelia.com mailto:mabdul...@karelia.com wrote: Step 1 of diagnosis: take a sample. How would that be accomplished ? A simple user-facing way is to fire up Activity Monitor, select your app, and sample it. More properly, use Instruments. To learn how, try watching some WWDC videos on the subject. ___ 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: drawRect runs twice, bounds are changed in between
On Jan 13, 2015, at 9:25 PM, N!K pu56ucl...@alumni.purdue.edu wrote: A breakpoint at the end of drawRect shows that it runs twice. After the second pass, the view appears, as it should. Between passes, bounds is changed somehow, as shown by NSLog at the start and end of drawRect. Since this will upset code that I will add later, I’d like to stop this. The view's being resized, probably as part of view layout. Ideally AppKit shouldn't draw the view before it gets to its final size, but maybe this is part of an animation, or maybe it's something that hasn't been optimized 100% in AppKit. In general, you should not make assumptions about when and how often -drawRect: will be called. That's up to AppKit. Your job is just to draw the view when you're told to. You haven't said why the bounds change will upset your code; is the view being changed to the wrong size? That would be an actual problem, but it isn't related to being drawn multiple times. You'd need to look at the view constraints in your window to diagnose that. —Jens ___ 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: drawRect runs twice, bounds are changed in between
On Jan 13, 2015, at 21:25 , N!K pu56ucl...@alumni.purdue.edu wrote: I have not been able to find a reason for this behavior. . I don’t know how to reveal the point between passes where bounds is actually changed. It does not happen in any other NSView projects of mine; drawRect runs only once in them The immediate reason is probably that the view’s size changed, which is not unlikely when the window is in the process of being displayed. The view may be resized for a “local” reason, such as the application of auto layout constraints, or for a “global” reason, such as the containing being resized and the change filtering down to subviews. Another possibility is that the view didn’t change size, but that (as an implementation detail of the Cocoa drawing system) it received two partial invalidations, and these weren’t coalesced in this case. I would like to prevent the second pass, or at least prevent the bounds change between passes. I don’t see any practical way to prevent ‘drawRect’ from being called again. Redundant ‘drawRect’ calls can occur any time during the view’s lifetime. Are you implying that one bounds rect is “right” and one is “wrong”? If so, how do you know that, and why can’t you just make your code do nothing if the bounds are “wrong”? If the only criterion is that the *last* bounds rect is “right”, you’ve got a big problem, because there’s no such concept in the drawing system. If you’re hoping that someone can suggest a solution, you probably need to be more specific about what “right” and “wrong” mean. I’m reluctant to try restoring bounds to its first value. I appreciate Ken Thomases’ warning in a previous subject not to change bounds in drawRect. I’d say it wasn’t a warning, but rather an injunction to never, ever do that. Doing so is Wile E. Coyote stuff. ___ 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: Debugging memory leak in NSURLSession with ARC
On 13 Jan 2015, at 01:00, Graham Cox graham@bigpond.com wrote:
I'm still having an issue with this - I think.
I've exhaustively hunted down every leak and memory allocation in my app -
luckily it's a fairly small one, though one that can create many threads -
and have eliminated everything I have control over*
My heap space is still growing over time. I'm having a LOT of trouble
understanding how to use Allocations Instrument effectively - I just can't
really understand what it's trying to tell me. I have read the documentation
for Allocations but it's not really much help, because it's hard for me to
'mark generations' when a 'generation' is something that happens as a result
of external factors, not a user-interface action.
I've satisfied myself that possible issues to do with blocks causing
potential retain cycles are definitely not the issue, nor is fumbling my way
using ARC for the first time**.
What I'm left with is either a genuine memory leak that occurs inside the
CFNetwork framework, or an apparent memory leak that isn't one really that I
can safely ignore. I'm just not sure which.
To recap, what my app does is to record chunks of video data to a file using
NSURLSession and NSURLSessionDataTask. These chunks are obtained by parsing a
.m3u8 playlist file. Each 'chunk' is a unique URL which is generated by the
server and persists for a fairly short time. By concatenating the data
returned by each fetch of these URLs, a complete capture of a live stream is
achieved. Overall, this process works great with the nagging problem of
growing memory usage. This growth appears to be somewhat related (but not
exactly correlated with) the amount of data downloaded and recorded. For
example, at first the leak is somewhat larger than what I record, but over
time it becomes quite a bit smaller. However if I record nothing, there is no
leak. What concerns me is that the leak can get large - after a day or so
of running, it's getting up to 3GB for example.
In my NSURLSessionConfiguration, I have turned off the URLCache (set it to
nil) - there's no purpose to caching data for the chunks because they are
only ever accessed once. Similarly I've disabled cookies. What I should be
looking at is a straightforward uncached download of a URL, write that data
to disk and move on. Here's my config setup:
self.configuration = [NSURLSessionConfiguration
ephemeralSessionConfiguration];
NSDictionary* additionalHeaders =
@{@User-Agent:XViPadUserAgentString};
self.configuration.HTTPAdditionalHeaders = additionalHeaders;
self.configuration.HTTPCookieAcceptPolicy =
NSHTTPCookieAcceptPolicyNever;
self.configuration.HTTPCookieStorage = nil;
self.configuration.URLCache = nil;
self.session = [NSURLSession
sessionWithConfiguration:self.configuration];
One small suggestion: I think the frameworks would prefer it if you copied the
ephemeralSessionConfiguration, and then modified the copy. Modifying this
shared config is probably not supported, and while it might work now, might not
in future.
___
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: Debugging memory leak in NSURLSession with ARC
leaks, not bugs. Kevin On 13 Jan 2015, at 10:21, Kevin Meaney k...@yvs.eu.com wrote: On 13 Jan 2015, at 02:51, Graham Cox graham@bigpond.com wrote: On 13 Jan 2015, at 12:21 pm, Roland King r...@rols.org wrote: Did you read the devforums thread I pointed you at a couple of weeks ago? Umm, not sure Roland. I read the blog post by bbum about using Allocations, which is the one you linked in this thread. Did you mean something else? Forgive me, I can't locate the link if so. If you're referring to bbum's post, I read that. I'm assuming that heapshot is now labelled mark generations but otherwise is the same thing. The problem with this in my case is that a generation is a new URL download and that's fired off automatically by either the previous one completing or a timer that's set to a variable time based on the target time of the playlist entry. There's no clear means for me to hit mark generation at exactly the right time. That might not matter all that much in that the process is continuous, so as long as I'm downloading a stream at a fairly steady rate, and hit the button at regular intervals, there should be a reasonable similarity between runs. Doing that, I get inconclusive results. Most of the memory that is left is like this: Snapshot Timestamp Growth # Persistent Generation B 01:32.780.375 2.09 MB 38 VM: Performance tool data2.08 MB 4 0x116816000 01:13.421.801 532.00 KB 0x1162ed000 01:32.145.259 532.00 KB 0x11614 01:23.051.011 532.00 KB 0x1161e5000 01:02.847.030 532.00 KB Which suggests it's memory allocated by Allocations itself. But where I'm checking this over longer time periods isn't in Instruments at all, but in Xcode's memory viewer. Unfortunately that doesn't give me a breakdown, just an overall usage. I went through a similar painful process in early November hunting down bugs. I'm not using NSURLConnection so I can't really comment about that API and I'm working on OS X. This comment and the remarks a little later in this thread referring to Quinn triggered a recollection. In desperation I looked at things using Activity Monitor's memory section and turned on the columns Real Mem, Shared Mem, and Purgeable Mem. In my case what I was seeing as a leak matched with the memory marked as purgeable. Exactly what is meant by purgeable I don't know beyond the obvious. Kevin ___ 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/ktam%40yvs.eu.com This email sent to k...@yvs.eu.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: licence key validation method
On 13 Jan 2015, at 13:51, Jens Alfke j...@mooseyard.com wrote: The license mechanism serves as a reminder to new users that their demo has expired, or that the copy they borrowed from their roommate hasn't been paid for yet. Precisely. I haven't commented on this frankly-OT-but-what-the-heck-I'll-talk-to-anyone-I'm-gregarious-that-kind-of-way subthread so far, but my use of licence keys has NOTHING to do with stopping piracy (good job too, given the obvious failures the big SW companies experience in their attempts at doing so). I'm implementing licence keys partly because paying customers expect them (it adds a shine of professionalism), and partly so that I can drive sales with trial modes, unlock features and so on. If someone wants to use my app without paying for it, fine. I don't really have much of a problem with that. All the apps I've done before this have been Freeware' or DonateWare anyway. That's why I've never tackled this licence key validation process before (as Allan linked to an earlier thread, I should point out I did ask this question once before, but with that app I gave up and just released it as freeware). It's just that with this app (and the next couple I've got coming through) I'd like to give people more incentive to buy. Best Phil ___ 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: Debugging memory leak in NSURLSession with ARC
On 13 Jan 2015, at 02:51, Graham Cox graham@bigpond.com wrote: On 13 Jan 2015, at 12:21 pm, Roland King r...@rols.org wrote: Did you read the devforums thread I pointed you at a couple of weeks ago? Umm, not sure Roland. I read the blog post by bbum about using Allocations, which is the one you linked in this thread. Did you mean something else? Forgive me, I can't locate the link if so. If you're referring to bbum's post, I read that. I'm assuming that heapshot is now labelled mark generations but otherwise is the same thing. The problem with this in my case is that a generation is a new URL download and that's fired off automatically by either the previous one completing or a timer that's set to a variable time based on the target time of the playlist entry. There's no clear means for me to hit mark generation at exactly the right time. That might not matter all that much in that the process is continuous, so as long as I'm downloading a stream at a fairly steady rate, and hit the button at regular intervals, there should be a reasonable similarity between runs. Doing that, I get inconclusive results. Most of the memory that is left is like this: Snapshot Timestamp Growth # Persistent Generation B 01:32.780.375 2.09 MB 38 VM: Performance tool data 2.08 MB 4 0x116816000 01:13.421.801 532.00 KB 0x1162ed000 01:32.145.259 532.00 KB 0x11614 01:23.051.011 532.00 KB 0x1161e5000 01:02.847.030 532.00 KB Which suggests it's memory allocated by Allocations itself. But where I'm checking this over longer time periods isn't in Instruments at all, but in Xcode's memory viewer. Unfortunately that doesn't give me a breakdown, just an overall usage. I went through a similar painful process in early November hunting down bugs. I'm not using NSURLConnection so I can't really comment about that API and I'm working on OS X. This comment and the remarks a little later in this thread referring to Quinn triggered a recollection. In desperation I looked at things using Activity Monitor's memory section and turned on the columns Real Mem, Shared Mem, and Purgeable Mem. In my case what I was seeing as a leak matched with the memory marked as purgeable. Exactly what is meant by purgeable I don't know beyond the obvious. Kevin ___ 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: licence key validation method
On 13 Jan 2015, at 07:42, João Varela joaocvar...@gmail.com wrote: all I’m saying be careful how you expose your licensing code if you are going to use objective C. I take the opposite POV. If someone's going to start messing around with otool and class-dump on my app, I know they're not going to be a paying customer. Why should I waste my time with obfuscation just to provide such people with a more educational challenge? It's rather analogous to shoplifting. Stores don't put electronic tags on goods to stop the professional thieves (because professionals have the same removal tools that the counter staff have). They put them on there to: i. suggest the item is of value and worth paying for; and ii. to stop the person who 99/100 times would pay, but might just have an aberration if you make it painfully easy for them to walk out the door without doing so. Nevertheless, if they really don't want to pay for it, they're not going to pay for it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging memory leak in NSURLSession with ARC
On 13 Jan 2015, at 8:11 pm, Mike Abdullah mabdul...@karelia.com wrote: One small suggestion: I think the frameworks would prefer it if you copied the ephemeralSessionConfiguration, and then modified the copy. Modifying this shared config is probably not supported, and while it might work now, might not in future. My reading of the docs is that these convenience methods create new objects, not return shared ones. I'll check again, though. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging memory leak in NSURLSession with ARC
On 13 Jan 2015, at 13:05, Graham Cox graham@bigpond.com wrote: On 13 Jan 2015, at 8:11 pm, Mike Abdullah mabdul...@karelia.com wrote: One small suggestion: I think the frameworks would prefer it if you copied the ephemeralSessionConfiguration, and then modified the copy. Modifying this shared config is probably not supported, and while it might work now, might not in future. My reading of the docs is that these convenience methods create new objects, not return shared ones. I'll check again, though. Upon a re-read, I think you’re probably right. The docs for +defaultSessionConfiguration are certainly clear on the subject, and it seems to reasonable to assume +ephemeralSessionConfiguration follows the same behaviour. ___ 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
NSThread
I allocate and init an NSThread as follows: if ( m_mythread ) [m_mythread cancel]; m_mythread = [[MYThread alloc] initWithTarget:m_mythread selector:@selector(start) object:m_anobject]; [m_mythread start]; I set a break in -start and see that this is a separate thread in my process ... so far so good. But, my UI becomes unresponsive. I understand that the main thread handles the UI so why would it become unresponsive? The overall behavior is as if the head code was executing in the main thread. Can some light be shed on this? I just did [m_bfilenameListFromPath setThreadPriority:0.5]; before [m_mythread start]; with the same result : unresponsive UI, wait cursor (beach ball) is displayed. -rags ___ 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: NSThread
On 13 Jan 2015, at 16:07, Raglan T. Tiger r...@crusaderrabbit.net wrote: I allocate and init an NSThread as follows: if ( m_mythread ) [m_mythread cancel]; m_mythread = [[MYThread alloc] initWithTarget:m_mythread selector:@selector(start) object:m_anobject]; [m_mythread start]; I set a break in -start and see that this is a separate thread in my process ... so far so good. But, my UI becomes unresponsive. I understand that the main thread handles the UI so why would it become unresponsive? The overall behavior is as if the head code was executing in the main thread. Can some light be shed on this? I just did [m_bfilenameListFromPath setThreadPriority:0.5]; before [m_mythread start]; with the same result : unresponsive UI, wait cursor (beach ball) is displayed. So you have a hang (by the sounds of it on OS X). Step 1 of diagnosis: take a sample. ___ 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: Debugging memory leak in NSURLSession with ARC
May I just jump in to say that you probably should be discussing this on the macnetworkprog list? There are people on that list (esp. Quinn) who are experts in this area. —Jens ___ 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: NSThread
On Jan 13, 2015, at 9:57 AM, Mike Abdullah mabdul...@karelia.com wrote: On 13 Jan 2015, at 16:18, Mike Abdullah mabdul...@karelia.com wrote: On 13 Jan 2015, at 16:07, Raglan T. Tiger r...@crusaderrabbit.net wrote: I allocate and init an NSThread as follows: if ( m_mythread ) [m_mythread cancel]; m_mythread = [[MYThread alloc] initWithTarget:m_mythread selector:@selector(start) object:m_anobject]; [m_mythread start]; Looking closer, I have to wonder what you think this code will do. You seem to be trying to create a thread that will message *itself* to do its work. Not only that, but I bet it infinite loops restarting itself. 1. Use init, not initWithTarget. 2. Override -main to do your threaded work. corbin At the time this code is executed, m_mythread will either be nil, or will point to an older thread instance that you’re about to supersede. I think you need to take a step back and evaluate your app design. What are you actually trying to accomplish here? Would using NSOperationQueue or GCD better suit your needs? ___ 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/corbind%40apple.com This email sent to corb...@apple.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
