> On Jul 22, 2016, at 19:29 , Graham Cox wrote:
>>
>> If the worker thread is waiting for -performOnMainThread to complete, it
>> *cannot* possibly get a call from the main thread to terminate
>
> I nodded agreement when I first read this, then “but wait!” …
>
> Your logic seems flawed on two c
On Jul 22, 2016, at 9:29 PM, Graham Cox wrote:
>
>
>> On 23 Jul 2016, at 12:45 AM, Trygve Inda wrote:
>>
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main th
On Jul 22, 2016, at 19:29 , Graham Cox wrote:
>
> If the worker thread is waiting for -performOnMainThread to complete, it
> *cannot* possibly get a call from the main thread to terminate
I nodded agreement when I first read this, then “but wait!” …
Your logic seems flawed on two counts:
1. T
> On 23 Jul 2016, at 12:45 AM, Trygve Inda wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block w
> On Jul 22, 2016, at 2:46 AM, Gerriet M. Denkmann wrote:
>
> When it gets some streams it will show a panel:
> “MyApp wants to sign using key “something” in your keychain” / “Allow” “Deny”
Presumably this app is either acting as an SSL server, or is sending SSL
clients. Either of those roles
Debug it some other way than with Xcode. Possibly you have a serious
bug, but running under the debugger alters something so that the bug
isn't stimulated.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
Or better yet, have the termination request come from a thread other than the
main thread.
> On Jul 22, 2016, at 9:38 AM, Alan Snyder wrote:
>
>
>> On Jul 22, 2016, at 7:45 AM, Trygve Inda wrote:
>>
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it d
> On Jul 22, 2016, at 7:45 AM, Trygve Inda wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block w
Go to Window -> Devices -> View Device Logs
-Carl
> On Jul 22, 2016, at 4:17 AM, Charles Jenkins wrote:
>
> Thank you all. I’ll start my research on how to find crash logs.
>
> On Thu, Jul 21, 2016 at 10:30 AM, Roland King wrote:
>
>>
>>> On 21 Jul 2016, at 22:15, Steve Bird wrote:
>>>
>
>> Currently it blocks at this point, but I need to avoid that.
>
> It’s not really clear why this needs to be avoided. The time to draw the
> pixels should be a few milliseconds, a small fraction of the time your thread
> needs to run, even at its fastest.
Because the main thread sometimes nee
> On 22 Jul 2016, at 11:53 PM, Trygve Inda wrote:
>
> How can I draw the NSImageRep directly into a window?
-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:];
i.e. same as NSImage.
>
> Also, the main pixel buffer is updated slowly (it takes a long time to
> draw).
>
>> On 22 Jul 2016, at 4:08 PM, Trygve Inda wrote:
>>
>> I don't think the second part will work because of my workflow:
>>
>> At Launch: Create pixel buffer that is 1000 x 1000 pixels
>>
>> Looping thread
>> 1. Fill pixel buffer with pixels based on some algorithm
>> 2. create an NSImage wit
>> This is how it works now, but we are running into a rare deadlock situation
>> where the main thread asks the worker thread to end (and waits until it does
>> so) while the worker thread is waiting for the image to be displayed.
>
> If the window has a imageRep property that is (atomic, copy)
Thank you all. I’ll start my research on how to find crash logs.
On Thu, Jul 21, 2016 at 10:30 AM, Roland King wrote:
>
> > On 21 Jul 2016, at 22:15, Steve Bird wrote:
> >
> >
> >> On Jul 21, 2016, at 10:05 AM, Eric E. Dolecki
> wrote:
> >>
> >> I believe that debug apps built directly to hard
I have an app (macOS 11.6) which uses kCFStreamPropertySSLSettings.
When it gets some streams it will show a panel:
“MyApp wants to sign using key “something” in your keychain” / “Allow” “Deny”
When I click “Deny” the streams get NSOSStatusErrorDomain errSecAuthFailed.
Else (clicked “Allow”) the
> On 22 Jul 2016, at 5:30 PM, Quincey Morris
> wrote:
>
> On Jul 22, 2016, at 00:08 , Graham Cox wrote:
>>
>> If the thread building images never goes faster than once per second, the
>> time to draw the image is a fraction of that - I’m sure 60fps is achievable,
>> so making the thread wai
On Jul 22, 2016, at 00:08 , Graham Cox wrote:
>
> If the thread building images never goes faster than once per second, the
> time to draw the image is a fraction of that - I’m sure 60fps is achievable,
> so making the thread wait for the drawing to be done isn’t going to hold it
> up signific
>
>> On 22 Jul 2016, at 4:40 PM, Trygve Inda wrote:
>>
>>
>>> With half an eye on performance, if you *do* strictly need a copy of the
>>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>>> turn it into a TIFF and back again.
>>>
>>> Also, you don’t even need an NS
> On 22 Jul 2016, at 5:00 PM, Roland King wrote:
>
> Since you need the data to persist for display whilst you write a new image
> that means there’s two separate buffers, there has to be
Not sure there HAS to be. Whether it’s the easiest approach is another matter.
If the thread building ima
> On 22 Jul 2016, at 14:40, Trygve Inda wrote:
>
>
>> With half an eye on performance, if you *do* strictly need a copy of the
>> bitmap, note that NSBitmapImageRep conforms to NSCopying. You don’t have to
>> turn it into a TIFF and back again.
>>
>> Also, you don’t even need an NSImage - the
20 matches
Mail list logo
