Skip to content

osx: thread id and signal stack support#1373

Merged
mattklein123 merged 4 commits intoenvoyproxy:masterfrom
turbinelabs:osx-4-thread-and-signal
Aug 2, 2017
Merged

osx: thread id and signal stack support#1373
mattklein123 merged 4 commits intoenvoyproxy:masterfrom
turbinelabs:osx-4-thread-and-signal

Conversation

@zuercher
Copy link
Copy Markdown
Member

@zuercher zuercher commented Aug 2, 2017

Modifies source/common/common/thread.cc to retrieve a thread id on OS X.

Modifies source/exe/signal_action.cc to retrieve RIP in OS X. Increases alt stack size used for signal handlers to meet the OS minimum values. Handles an OS X bug where disabling the alt signal stack fails because the size field in the original stack_t is less than MINSIGSTKSZ.

(Split out from #1348, in support of #128.)

Copy link
Copy Markdown
Contributor

@dnoe dnoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good, one question about the thread ID.

Comment thread source/common/common/thread.cc Outdated
return syscall(SYS_gettid);
#elif defined(__APPLE__)
int ret = mach_thread_self();
mach_port_deallocate(mach_task_self(), ret);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I didn't catch this the first time. I found some info while searching about mach_thread_self/mach_port_deallocate:

https://codereview.chromium.org/276043002/

Did you try pthread_mach_thread_np(pthread_self())?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Thanks.

Comment thread source/common/common/thread.cc Outdated
#ifdef __linux__
return syscall(SYS_gettid);
#elif defined(__APPLE__)
return pthread_mach_thread_np(pthread_self());
Copy link
Copy Markdown
Contributor

@PiotrSikora PiotrSikora Aug 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for not using pthread_threadid_np() here?

uint64_t tid;
pthread_threadid_np(NULL, &tid);
return tid;

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current method has the advantage of returning 32 bit ints. After some experimentation the values from the current method end up being repeatable across executions. Given that currentThreadId is used as part of a seed for a random number generator in source/common/runtime/runtime_impl.h, I'll switch to returning the low order bits of pthread_threadid_np's thread id.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage of returning 32 bits, exactly? Why can't we return full 64 bits?

And yes, kernel thread numbers (returned by pthread_mach_thread_np()) are quite aggressively recycled, AFAIK.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no advantage to 32 bits beyond keeping this change local to this file.

return syscall(SYS_gettid);
#elif defined(__APPLE__)
uint64_t tid;
pthread_threadid_np(NULL, &tid);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just use this on all platforms now and lose ifdef? feel free to return uint64_t and lose the static cast if you want.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no pthread_threadid_np() on Linux.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, ok. nevermind me. :)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That function doesn't exist on Linux.

mattklein123
mattklein123 previously approved these changes Aug 2, 2017
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


int32_t Thread::currentThreadId() { return syscall(SYS_gettid); }
int32_t Thread::currentThreadId() {
#ifdef __linux__
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: could you either add #else case or use Linux as the fallback? i.e.

#if defined(__linux__)
  return syscall(SYS_gettid);
#elif defined(__APPLE__)
  uint64_t tid;
  pthread_threadid_np(NULL, &tid);
  return tid;
#else
#error "OS not supported."
#endif

or

#ifdef __APPLE__
  uint64_t tid;
  pthread_threadid_np(NULL, &tid);
  return tid;
#else
  return syscall(SYS_gettid);
#endif

otherwise we're going to end with code that doesn't have return value on other OSes.

Either one is fine with me, assuming @mattklein123 doesn't have any objections.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I thought about this. Agree this would be a bit nicer. Either way the compile will fail so not sure it matters that much. No preference from me about either of these or leaving what we have.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an #error directive.

@mattklein123 mattklein123 merged commit c4fa6e6 into envoyproxy:master Aug 2, 2017
@zuercher zuercher deleted the osx-4-thread-and-signal branch August 10, 2017 16:06
jpsim pushed a commit that referenced this pull request Nov 28, 2022
Description: fixes two leaks in the platform filter chain. One in the common code, and one specific to iOS
Risk Level: low
Testing: ran with Lyft's Driver app under xcode's memory profiler.

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit that referenced this pull request Nov 29, 2022
Description: fixes two leaks in the platform filter chain. One in the common code, and one specific to iOS
Risk Level: low
Testing: ran with Lyft's Driver app under xcode's memory profiler.

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
mathetake added a commit that referenced this pull request Mar 3, 2026
…1373)

**Description**

Despite the documentation about "messages" operation, the anthropic
messages processor was wrongly using the chat completions metrics
implementation hence the metrics produced in /messages endpoint were
mixed up with the ones in /chat/completions metrics.

This fixes it and make it in line with the documentation.

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants