Re: [RFC] Enable thread termination

[Neal H. Walfield]

At Sun, 17 Nov 2013 17:13:23 +0100,
Richard Braun wrote:
> The current state is to never terminate threads, on the assumption that
> they can't both terminate and release their stack on their own. Such
> resources are recycled by the threading library.  This patch makes use
> of a new GNU Mach specific call (thread_terminate_release [1]) so that
> threads do terminate themselves and release their stack, and in addition
> their last self reference, and their reply port.

Eliminating bugs should be our first priority.  However, recycling
threads is a good idea, particularly when the application sees threads
as lightweight resources.  Ideally, there is some mechanism that
identifies thread churn and sizes the reserve thread pool
appropriately (e.g., the maximum of the maximum number of live threads
during each minute in the past 5 minutes).  Note: this isn't a reason
not to apply the patch, but should perhaps be noted as possible future
work.

> To avoid right leaks, the sigstate maintains its own reference on its
> associated thread. Reusing the self reference created from libpthread
> isn't possible because the sigstate of the main thread is created
> before (actually during, because of _hurd_critical_section_lock being
> called early) libpthread initialization, when there is no self reference
> for the main thread yet. This relies on GNU Mach always using the same
> name for already existing send rights (i.e. mach_task_self always
> returns the same name as long as it's not destroyed).

This assume is reasonable: it is true and used often.

> Joining/detaching relies on pthread structures maintaining a reference
> counter. Joinable threads have 2 references, detached threads only one
> (a self reference). This replaces the previous mechanism that forced
> thread to halt before checking their state.
> 
> A few static variables were added to record that initialization had been
> done, instead of merely looking at the current number of threads.
> 
> Two resources are still recycled: the internal pthread structure
> (because it makes ID allocation easy), and thread local storage (TLS)
> because that's where the reply port is stored, and it didn't seem
> convenient to call _dl_deallocate_tls in sysdeps code.

Conceptually, your approach seems fine, but I haven't reviewed the
patch in detail.

Neal