Re: NSImage drawInRect deadlock
Re: NSImage drawInRect deadlock
- Subject: Re: NSImage drawInRect deadlock
- From: Andrew Keller <email@hidden>
- Date: Tue, 09 Aug 2016 08:38:01 -0400
Am 08.08.2016 um 8:12 nachm. schrieb Kyle Sluder <email@hidden>:
>
> On Mon, Aug 8, 2016, at 05:11 PM, Jens Alfke wrote:
>>
>>> On Aug 8, 2016, at 2:54 PM, Aaron Tuller <email@hidden> wrote:
>>>
>>> "The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time."
>>
>> The images are only being used on one thread at a time. The problem seems
>> to be that the NSImage _cache_ is shared and (apparently) not
>> thread-safe.
>
> I wouldn’t jump immediately to thread-unsafety. It’s possible that
> Andrew is simply exhausting the thread pool.
>
> Andrew, are you doing anything to limit the amount of decode operations
> you’re putting on the global queue?
Not presently. Under normal usage, it hovers around 10-40 threads, but I’ve seen it as high as 200. Honestly, I was hoping to limit it to 3 or 6 — just experimentally, one thread by itself can saturate roughly 20-30% of my i7 processor. If 3-6 simultaneous operations will saturate the whole processor, I don’t see much value in letting it go much higher than that.
What is the preferred way to limit the number of parallel operations in the global queue? I was under the impression from the docs that macOS handles the thread pool “automatically”.
Thanks,
- Andrew
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden