On Mon, Nov 25, 2013 at 12:45 PM, Matthieu Bouron wrote:
>
> On Sun, Nov 10, 2013 at 10:50 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com> wrote:
>
>> Hello,
>>
>> First of all, sorry in advance if i'm not addressing the right mailing
>> list.
>>
>> I'm currently using the CVPixelBufferRef API
Here¹s the repository containing my HTML pages
https://github.com/leonardodev/htmlpages
Regards
-- Leonardo
Da: Jens Alfke
Data: Sat, 4 Jan 2014 13:40:09 -0800
A: Leonardo
Cc:
Oggetto: Re: NSHTMLTextDocumentType returns wrong font names
On Jan 4, 2014, at 3:03 AM, Leonardo wrote:
> I'm t
When my read stream finishes I schedule a timer to clean up on the runloop to
serialize access to shared resources.
However, I had a hang late last night because a mutex grabbed in the read
stream callback handler was held and was also being grabbed when the timer it
scheduled to clean up fired
On Jan 5, 2014, at 4:37 PM, Jim O'Connor wrote:
>
> When my read stream finishes I schedule a timer to clean up on the runloop to
> serialize access to shared resources.
> However, I had a hang late last night because a mutex grabbed in the read
> stream callback handler was held and was also b
I punctuated that poorly.
I can run the CFRunLoop myself. Or it is (nearly) the top level for the thread,
typically.
It shouldn't be the case that timers fire other than with a CFRunLoop() just
above them in the stack, though, right?
As I said, it was really late after a long long day, so maybe
On Jan 5, 2014, at 4:37 PM, Jim O'Connor wrote:
> When my read stream finishes I schedule a timer to clean up on the runloop to
> serialize access to shared resources.
> However, I had a hang late last night because a mutex grabbed in the read
> stream callback handler was held and was also be
I'd try to reproduce the deadlock and post the stack trace. It looks
like CFStream (http://opensource.apple.com/source/CF/CF-855.11/CFStream.c)
runs the run loop in the default mode in only one situation, but
that's only after spawning its own thread to do it in.
___
Like I said, it was late at night…
XCode hides stack frames it thinks are unimportant.
Like the stack frame that had the CFRunLoop in it inside a
CFMessagePortSendRequest.
I found the problem when I copied out the stack crawl to show a friend, and low
and behold there were 4 extra stack frames
On Jan 5, 2014, at 6:31 PM, Jim O'Connor wrote:
>
> XCode hides stack frames it thinks are unimportant.
> Like the stack frame that had the CFRunLoop in it inside a
> CFMessagePortSendRequest.
>
> I found the problem when I copied out the stack crawl to show a friend, and
> low and behold ther