• dsimcha (8/8) Apr 29 2009 Would it be easy to put into core.thread a mechanism that would guarante...
• Sean Kelly (4/9) Apr 29 2009 It seems like this would be easy to do in an app without modifying the r...
• dsimcha (11/20) Apr 29 2009 I'm talking about if you write some generic lib that needs something lik...
• Sean Kelly (6/19) Apr 29 2009 Hm, so you want druntime to execute an arbitrary number of functions on ...

dsimcha <dsimcha yahoo.com> writes:

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.

Sean Kelly <sean invisibleduck.org> writes:

== 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?

dsimcha <dsimcha yahoo.com> writes:

== 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.

Sean Kelly <sean invisibleduck.org> writes:

== 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.