Bug 1085 – Need to add ability to detach threads.

It is not always reasonable to use wait() to clean up thread resources. I would like to see a detach method for threads or a DetachedThread class added to the library.

For what it's worth, Tango will implicitly detach any thread for which pthread_join has not been called by the time the the Thread object is destroyed. I think this is the preferred approach for D, since some required functionality of the Thread object may not work if the thread has been detached prematurely.

This doesn't seem dgcc/gdc specific and assuming not should be re-assigned to the more general D / Phobos bucket.

I think that assuming that a thread should detach just because no thread called wait() before the thread exits is incorrect. It is certainly within the posix programming model to use wait to collect status of previously exited threads and that should probably be exposed. I think either an explicit detach() method, or a separate subclass for detached threads would be better than the Tango model. I agree that this is general to D and am moving it to that category.

[email protected] wrote: > > ------- Comment #3 from [email protected] 2007-03-28 23:20 ------- > I think that assuming that a thread should detach just because no thread called > wait() before the thread exits is incorrect. It is certainly within the posix > programming model to use wait to collect status of previously exited threads > and that should probably be exposed. I think either an explicit detach() > method This would be reasonable for Posix, but now Win32. On Posix, the thread handle isn't needed for any of the currently exposed functionality (though it may be for future functionality, such as modifying thread priorities). On Win32 however, the thread handle is required for pretty much everything, including suspending the thread for garbage collection. So the only recourse would be to make detach() a no-op on Win32, and to consider the use of some functions an error after detach() is called on Posix. > or a separate subclass for detached threads would be better than the > Tango model. The user is free to subclass Thread and do whatever he wants, subject to the aforementioned restrictions. But design issues at this level are better discussed elsewhere.

*** Issue 12812 has been marked as a duplicate of this issue. ***

This is a druntime issue. Changing component to druntime

Is this issue solved by core.thread : thread_detachByAddr, thread_detachInstance, thread_detachThis ? https://dlang.org/phobos/core_thread.html#.thread_detachByAddr

As indicated in comment #7, the issue is resolve by the features present in core.thread.threadbase.