Thread overview
Thread ctors/dtors
Apr 29, 2009
dsimcha
Apr 30, 2009
Sean Kelly
Apr 30, 2009
dsimcha
Apr 30, 2009
Sean Kelly
April 29, 2009
Would it be easy to put into core.thread a mechanism that would guarantee that a set of callback functions were called from any newly created thread upon creation, or by any thread just before termination?  Of course, by thread termination, I mean if the thread terminates normally because it finishes its job, not if it gets killed externally.

If this is reasonably implementable, do others feel it belongs in druntime? If I wrote a good patch to do this, would it likely get accepted?  I think ideas like this have been suggested before, but not really followed up on.
April 30, 2009
== Quote from dsimcha (dsimcha@yahoo.com)'s article
> Would it be easy to put into core.thread a mechanism that would guarantee that a set of callback functions were called from any newly created thread upon creation, or by any thread just before termination?  Of course, by thread termination, I mean if the thread terminates normally because it finishes its job, not if it gets killed externally.

It seems like this would be easy to do in an app without modifying the runtime. Or is there some need to hook the initialization and termination of threads you don't own?
April 30, 2009
== Quote from Sean Kelly (sean@invisibleduck.org)'s article
> == Quote from dsimcha (dsimcha@yahoo.com)'s article
> > Would it be easy to put into core.thread a mechanism that would guarantee that a set of callback functions were called from any newly created thread upon creation, or by any thread just before termination?  Of course, by thread termination, I mean if the thread terminates normally because it finishes its job, not if it gets killed externally.
> It seems like this would be easy to do in an app without modifying the runtime. Or is there some need to hook the initialization and termination of threads you don't own?

I'm talking about if you write some generic lib that needs something like this, and you don't want the users of the lib to have to do it manually every time they create a new thread.  For example, let's say you write a random number generation module, which has a thread-local global random number generator.  This generator is supposed to "just work" without the user having to do anything.  The way the new Phobos handles this is to check an internal flag.  A better way would be to add a callback that seeds the new random number generator every time a new thread is created.

Of course there are probably plenty of similar situations with less trivial workarounds.  This is just supposed to be an illustrative example.
April 30, 2009
== Quote from dsimcha (dsimcha@yahoo.com)'s article
> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
> > == Quote from dsimcha (dsimcha@yahoo.com)'s article
> > > Would it be easy to put into core.thread a mechanism that would guarantee that a set of callback functions were called from any newly created thread upon creation, or by any thread just before termination?  Of course, by thread termination, I mean if the thread terminates normally because it finishes its job, not if it gets killed externally.
> > It seems like this would be easy to do in an app without modifying the runtime. Or is there some need to hook the initialization and termination of threads you don't own?
> I'm talking about if you write some generic lib that needs something like this, and you don't want the users of the lib to have to do it manually every time they create a new thread.

Hm, so you want druntime to execute an arbitrary number of functions on thread creation and termination, each of which could throw an exception?  Yuck :-)  I guess the functions could be required to be nothrow, but it still seems like a problem waiting to happen.  I could be convinced to make the change, but someone would have to present a compelling case for it.