Reviewed!
Thanks,
David
On 21/08/2013 6:44 PM, Staffan Larsen wrote:
I still need a Reviewer to ok this.
Thanks,
/Staffan
On 19 aug 2013, at 11:08, Staffan Larsen wrote:
We are using the mach thread port name as the os thread identifier on OS X. We get this
value by calling mach_thread_se
I still need a Reviewer to ok this.
Thanks,
/Staffan
On 19 aug 2013, at 11:08, Staffan Larsen wrote:
> We are using the mach thread port name as the os thread identifier on OS X.
> We get this value by calling mach_thread_self(), but we (I) didn't realize
> that this "port" resource is refere
On 21/08/2013 3:39 AM, Gerard Ziemski wrote:
On 8/20/2013 4:14 AM, Dmitry Samersoff wrote:
2. Why are we using the the "::" C++ name space before mach/pthread C
>APIs calls? I understand that you might be just following the existing
>pattern in the file, I'm just wondering if you, or anyone kno
On 8/20/2013 4:14 AM, Dmitry Samersoff wrote:
2. Why are we using the the "::" C++ name space before mach/pthread C
>APIs calls? I understand that you might be just following the existing
>pattern in the file, I'm just wondering if you, or anyone knows why.
C++ :: means global scope and it solv
On 2013-08-19 20:11, Gerard Ziemski wrote:
> hi Staffan,
>
> A search on the topic of Mac thread id reveals that pretty much everyone
> (including Apple itself) uses pthread_mach_thread_np() for thread id, so
> it looks like you're correct to use it.
>
> I do have some more quick feedback/questio
On 19 aug 2013, at 18:11, Gerard Ziemski wrote:
> hi Staffan,
>
> A search on the topic of Mac thread id reveals that pretty much everyone
> (including Apple itself) uses pthread_mach_thread_np() for thread id, so it
> looks like you're correct to use it.
>
> I do have some more quick feedba
I thought that was the recommended way of calling OS functions. We seem to have
both styles, though.
/Staffan
On 19 aug 2013, at 17:33, Gerard Ziemski wrote:
> hi Staffan,
>
> Why are we using the the "::" C++ name space before mach/pthread C APIs calls?
>
>
> cheers
>
> On 8/19/2013 4:08
hi Staffan,
A search on the topic of Mac thread id reveals that pretty much everyone
(including Apple itself) uses pthread_mach_thread_np() for thread id, so
it looks like you're correct to use it.
I do have some more quick feedback/questions:
1. Could the "just checking" string in guarantee
hi Staffan,
Why are we using the the "::" C++ name space before mach/pthread C APIs
calls?
cheers
On 8/19/2013 4:08 AM, Staffan Larsen wrote:
We are using the mach thread port name as the os thread identifier on OS X. We get this
value by calling mach_thread_self(), but we (I) didn't reali
Yeah... I don't know a way to check that without calling mach_thread_self.
Ideally pthreads should fail on pthread_create if we are out of resources, but
that doesn't seem to be the case.
/Staffan
On 19 aug 2013, at 12:15, Rickard Bäckman wrote:
> Staffan,
>
> the change looks good. (Not a R
Staffan,
the change looks good. (Not a Reviewer).
One thing to point out though, if we would leak ports the following line would
get stuck in an infinite loop
(pthread_mach_thread_np calls _pthread_lookup_thread which calls
_pthread_find_thread which will spin forever if the ports part of the p
We are using the mach thread port name as the os thread identifier on OS X. We
get this value by calling mach_thread_self(), but we (I) didn't realize that
this "port" resource is reference counted and mach_thread_self() increases the
reference count, but we never call mach_port_deallocate() to
12 matches
Mail list logo
