Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Merge ^/head r323559 through r325504.

MFhead@r325199

DIRDEPS_BUILD: Update dependencies.

Sponsored by: Dell EMC Isilon

Merge ^/head r305087 through r305219.

MFhead @ r305170

DIRDEPS_BUILD: Update dependencies.

Sponsored by: EMC / Isilon Storage Division

Merge ^/head r303250 through r304235.

Add __cxa_thread_atexit(3) API implementation.

This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword. A destructor for given
thread-local obje

Add __cxa_thread_atexit(3) API implementation.

This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword. A destructor for given
thread-local object is registered to be executed at the thread
termination time using __cxa_thread_atexit(). Libc calls the
__cxa_thread_calls_dtors() during exit(3), before finalizers and
atexit functions, and libthr calls the function at the thread
termination time, after the stack unwinding and thread-specific key
destruction.

There are several uncertainties in the API which lacks a formal
specification. Among them:
- is it allowed to register destructors during destructing;
we allow, but limiting the nesting level. If too many iterations
detected, a diagnostic is issued to stderr and thread forcibly
terminates for now.
- how to handle destructors which belong to an unloading dso;
for now, we ignore destructor calls for such entries, and
issue a diagnostic. Linux does prevent dso unload until all
threads with destructors from the dso terminated.
It is supposed that the diagnostics allow to detect real-world
applications relying on the above details and possibly adjust
our implementation. Right now the choices were to provide the slim
API (but that rarely stands the practice test).

Tests are added to check generic functionality and to specify some of
the above implementation choices.

Submitted by: Mahdi Mokhtari <mokhi64_gmail.com>
Reviewed by: theraven
Discussed with: dim (detection of -std=c++11 supoort for tests)
Sponsored by: The FreeBSD Foundation (my involvement)
MFC after: 2 weeks
Differential revisions: https://reviews.freebsd.org/D7224,
https://reviews.freebsd.org/D7427

show more ...

MFH

Sponsored by: The FreeBSD Foundation

DIRDEPS_BUILD: Connect MK_TESTS.

Sponsored by: EMC / Isilon Storage Division

Merge ^/head r323559 through r325504.

MFhead@r325199

DIRDEPS_BUILD: Update dependencies.

Sponsored by: Dell EMC Isilon

Merge ^/head r305087 through r305219.

MFhead @ r305170

DIRDEPS_BUILD: Update dependencies.

Sponsored by: EMC / Isilon Storage Division

Merge ^/head r303250 through r304235.

Add __cxa_thread_atexit(3) API implementation.

This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword. A destructor for given
thread-local obje

Add __cxa_thread_atexit(3) API implementation.

This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword. A destructor for given
thread-local object is registered to be executed at the thread
termination time using __cxa_thread_atexit(). Libc calls the
__cxa_thread_calls_dtors() during exit(3), before finalizers and
atexit functions, and libthr calls the function at the thread
termination time, after the stack unwinding and thread-specific key
destruction.

There are several uncertainties in the API which lacks a formal
specification. Among them:
- is it allowed to register destructors during destructing;
we allow, but limiting the nesting level. If too many iterations
detected, a diagnostic is issued to stderr and thread forcibly
terminates for now.
- how to handle destructors which belong to an unloading dso;
for now, we ignore destructor calls for such entries, and
issue a diagnostic. Linux does prevent dso unload until all
threads with destructors from the dso terminated.
It is supposed that the diagnostics allow to detect real-world
applications relying on the above details and possibly adjust
our implementation. Right now the choices were to provide the slim
API (but that rarely stands the practice test).

Tests are added to check generic functionality and to specify some of
the above implementation choices.

Submitted by: Mahdi Mokhtari <mokhi64_gmail.com>
Reviewed by: theraven
Discussed with: dim (detection of -std=c++11 supoort for tests)
Sponsored by: The FreeBSD Foundation (my involvement)
MFC after: 2 weeks
Differential revisions: https://reviews.freebsd.org/D7224,
https://reviews.freebsd.org/D7427

show more ...

MFH

Sponsored by: The FreeBSD Foundation

DIRDEPS_BUILD: Connect MK_TESTS.

Sponsored by: EMC / Isilon Storage Division

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Merge ^/head r323559 through r325504.

MFhead@r325199