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
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():
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