Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore bringing back support for detach() #52

Open
dktapps opened this issue Feb 28, 2021 · 0 comments
Open

Explore bringing back support for detach() #52

dktapps opened this issue Feb 28, 2021 · 0 comments

Comments

@dktapps
Copy link
Member

dktapps commented Feb 28, 2021

detach() is useful for background throwaway tasks, as well as getting rid of threads that won't die on proc shutdown (e.g. PM's famously infuriating CommandReader issue on Windows).

Currently known obstacles to supporting detach():

  • Child threads currently directly reference non-permanent interned strings from their parent (user class strings). This is problematic because detach() would allow a parent thread to exit without joining the child thread, potentially resulting in UAF on the child.
  • detach() would permit Thread objects to be directly disposed without joining, which means that UAF could occur if detach() was used directly after starting a thread (the child thread has to copy some information from the parent thread, like the thread's class). This could be solved by making start() wait until the child thread was ready (but this would incur a performance hit). not a concern
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

No branches or pull requests

1 participant