We need public API for getting main thread object.
See also http://comments.gmane.org/gmane.comp.python.devel/141370

The function must take care of fork() in worker threads, too. The isinstance(current_thread(), _MainThread) trick may not work.

> The function must take care of fork() in worker threads, too. The
> isinstance(current_thread(), _MainThread) trick may not work.

Well, there are two possibilities:
- main_thread() returns the original _MainThread instance, even if it's
  dead in the child process
- main_thread() returns the main thread of the current process

Both are reasonable, but we must settle for one :-)

(also, the use case of forking from a thread is really obscure, I don't
think we should worry too much about it)

Patch with code and tests is attached.
Test fails when program forks from thread other than the main one.

signal module reinitializes main_thread variable in PyOS_AfterFork, threading does nothing with forking.

http://bugs.python.org/issue16500 is required to make work after fork from thread other than the main one.

> http://bugs.python.org/issue16500 is required to make work after
> fork from thread other than the main one.

No it isn't. Please take a look at _after_fork() in threading.py.

There is updated patch.
All tests pass.
I've added docs for threading.main_thread() function also.

Ok, some comments about the patch (no "review" links appears so I'm gonna do it inline here):

- the doc addition needs a "versionadded" tag

- "The main thread is the thread that the OS creates to run application.": I would rephrase this "In normal conditions, the main thread is the thread from which the Python interpreter was started".

- in the tests:
+        self.assertEqual(data, "Thread-1\nTrue\nTrue\n")

Hmm, how do you know it will be called "Thread-1"?
I would give a specific name to the Thread, so as to make the test deterministic.

+        self.assertEqual(rc, 0)

You don't need this, it is already ensured by assert_python_ok().

- in threading.py, why doesn't _exitfunc() reuse the _main_thread global variable, instead of taking it as a parameter?

Uploaded new patch.

> - the doc addition needs a "versionadded" tag
Fixed.

> - "The main thread is the thread that the OS creates to run application.": I would rephrase this "In normal conditions, the main thread is the thread from which the Python interpreter was started".
Fixed.

> - in the tests:
> +        self.assertEqual(data, "Thread-1\nTrue\nTrue\n")
> 
> Hmm, how do you know it will be called "Thread-1"?
> I would give a specific name to the Thread, so as to make the test deterministic.
In this test main thread after forking is always first thread created by python. That's why it always is called 'Thread-1'. 

> +        self.assertEqual(rc, 0)
> 
> You don't need this, it is already ensured by assert_python_ok().
Fixed.

> - in threading.py, why doesn't _exitfunc() reuse the _main_thread global variable, instead of taking it as a parameter?
Fixed.

New changeset 96e55a1a0de7 by Andrew Svetlov in branch 'default':
Issue #18882: Add threading.main_thread() function.
http://hg.python.org/cpython/rev/96e55a1a0de7

I don't think you saw my review, but could you add a docstring to the main_thread() function? Thanks!

I did not received review email, sorry.
Docstring is added.
BTW 'threading' module has almost no docstrings, that's why I've added only docs at first.
Do you think docstrings should be added to all public functions?
Thanks.

> BTW 'threading' module has almost no docstrings, that's why I've
> added only docs at first.
> Do you think docstrings should be added to all public functions?

Well, probably, although that's another issue :)

In msg196529 Antoine says there are two possible interpretations of main_thread, and we must choose one.  However, the documentation does not indicate which one was chosen.

Implementation uses the first choice:
main_thread() returns the original _MainThread instance, even if it's dead in the child process.

I'm sorry, would you guess desired documentation change?