There are two "barrier" like abstractions onLib/logging/handlers.py in the _monitor method.First _monitor has two loops, what is already kind of a hint something is not right.Second, it has two ways to exit the loop, that also exit the thread:1) The _stop threading.Event is "set"2) The _sentinel object is added to the queueThe problem is, the documentation says that the correct way to not loose records, the stop method must be called, but, the stop method just sets the _stop object and then adds the _sentinel object to the queue.The loop stops when noticing that _stop is set, and then enters a second version of the loop, trying again to see the _sentinel object, but this time with non blocking read.The test case shows the problem, but it also hints about the race conditions by the fact that running the test case under "taskset 1" works, so, to reproduce the issue, run the test under a multiprocessor environment.The proper solution would be to have a proper locking mechanism, otherwise, the _stop object should not be used, and rely only in seeing the _sentinel field; this is what the class DeterministicQueueListener does in the test case.(Reported by Paulo Andrade athttps://bugzilla.redhat.com/show_bug.cgi?id=1370484 )

Removed 3.3 and 3.4 as they are not in scope for non-security issues.

New changeset121b5b41c9e8 by Vinay Sajip in branch 'default':Fixes#27930: improved QueueListener behaviour.https://hg.python.org/cpython/rev/121b5b41c9e8New changesetb2ea0ede3753 by Vinay Sajip in branch '3.5':Fixes#27930: improved QueueListener behaviour.https://hg.python.org/cpython/rev/b2ea0ede3753New changeset89b185372b2c by Vinay Sajip in branch 'default':Closes#27930: Merged fix from 3.5.https://hg.python.org/cpython/rev/89b185372b2c