http://d.puremagic.com/issues/show_bug.cgi?id=1085


mattbd@walkingdog.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Phobos                      |Phobos
            Product|DGCC aka GDC                |D
            Version|0.23                        |unspecified




------- Comment #3 from mattbd@walkingdog.net  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, 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.


-- 

d-bugmail@puremagic.com wrote:
> 
> ------- Comment #3 from mattbd@walkingdog.net  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.